text:
The present invention provides a system and method for providing controlled service transactions involving multiple service providers on a service network. A client access device links to the service network via a network entry point and performs the multi-service provider transaction under the control of a network transactional application at a hub that holds the transaction captive and includes a router to route to remote distributed software objects at nodes of the service providers. The software objects include methods that may be remotely executed under the control of the transactional application at the hub.
1. A real-time on-line two-way transaction system, the system comprising:
a first server comprising memory and a processor;
a context manager executing on the first server supporting a first web page on the World Wide Web, the context manager allowing access by a user from a multi-media device through a Web application to a plurality of possible Web transactions from a plurality of Web merchants;
a user transaction manager in the Web application allowing the user to enter into a first transaction using a second web page;
an account settling manager in the Web application allowing the user to communicate with a payment program running on a second server remote from the first server, wherein the user can settle an account relating to the first transaction;
a switching component in the Web application that temporarily switches the user from the first server to the second server to allow settling of the account, wherein the user directly communicates with the payment program on the second server via an object router, the object router allowing the user to perform a real-time transaction from the Web application with at least one of the Web merchants while providing interaction and management between the first and second servers.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
7. The system of
8. The system of
9. The system of
10. A computer implemented method of permitting a real-time, online transaction by a user with at least one computing device on the World Wide Web, the method comprising:
presenting a first web page from a first server allowing a user to choose a Web transaction from a plurality of possible Web transactions;
presenting a second web page allowing the user to display the second web page on the computing device and to interactively enter into the Web transaction with a particular Web merchant;
switching the user transacting from a Web application on the first server to a payment server remote from the first server allowing the user to interactively settle the Web transaction in real-time, wherein the user directly communicates from a user device to the payment server; and
allowing the user to perform the Web transaction from the Web application via an object router with the Web merchant, while providing interaction and management between the first server and the payment server.
11. The method of
12. The method of
13. The method of
14. The method of
15. The method of
16. A system for purchasing a vehicle on the World Wide Web, the system comprising:
a first server comprising memory and a processor;
a transaction manager system in a Web application running on the first server presenting a first web page on the World Wide Web allowing a buyer to choose a category of vehicle;
a merchandise presentation system in the Web application for presenting a plurality of vehicles for sale in the category on a second web page;
a switching component in the Web application providing content to the buyer from a financing service, the content being located on a server remote from the first server, the switching component in the Web application routing a quote from the financing service to the buyer in real-time, the buyer directly communicating from a user device to the financing service;
a sales component in the Web application allowing the buyer to purchase the particular vehicle from the seller and obtain financing from the financing service in a real-time transaction; and
a communications component that includes an object router allowing the buyer to perform the real-time transaction from the Web application, while providing interaction and management between the first server and the remote server.
17. The system of
18. The system of
19. The system of
20. The system of
21. The system of
22. A system for creating an online Web merchant, the system comprising:
a first server comprising memory and a processor;
a content manager running on the first web server presenting a web page on the World Wide Web and allowing a user to choose a category of services in a Web application on the web page from a plurality of categories, the content manager also allowing a Web merchant to present a plurality of merchandise selections on a Web merchant web page, wherein the merchandise selections belong to at least one of said categories, the content manager also allowing a user to select one of the categories and switching the user to the merchant web page upon selection of a particular category from the Web application;
a transaction manager in the Web application allowing the user to enter into a real-time Web transaction with the Web merchant with respect to a first particular piece of merchandise, wherein the transaction manager switches the user to content from a web page provided by a transaction settlement service running on a second server remote from the first server, wherein the user can settle the Web transaction in real-time, and wherein the user directly communicates from a user device to the transaction settlement service; and
an object router module that allows the user to perform the real-time Web transaction from the Web application with the Web merchant, while providing interaction and management between the first server and the second server.
23. The system of
24. The system of
25. The system of
26. The system of
27. The system of
28. The system of
29. The system of
30. The system of
31. A real-time online, two-way transaction system, operating on the World Wide Web, the system comprising:
a first server comprising memory and a processor;
a content manager executing on the first server supporting a first web page on the World Wide Web, the content manager in a Web application on a web page allowing access by a user to a plurality of possible Web transactions from a plurality of Web merchants;
a user transaction manager allowing the user to enter into a first real-time Web transaction using a second web page, the user transaction manager in the Web application also allowing the user to enter into a second real-time Web transaction using a third web page;
an account settling manager in the Web application allowing the user to communicate with a payment program running on a second server remote from the first server, wherein the user can settle an account relating to the first Web transaction and the second Web transaction simultaneously;
a switching component in the Web application that temporarily switches the user from the first server to the second server to allow settling of the account in real-time, wherein the user communicates directly from a user device to the payment program; and
an object router module allowing the user to perform the real-time Web transactions from the Web application with at least one of the Web merchants while providing interaction and management between the first server and the second server.
32. The system of
33. The system of
34. The system of
35. The system of
36. The system of
37. The system of
38. The system of
39. The system of
40. The system of
This application is a continuation in part of application Ser. No. 09/792,323 filed Feb. 23, 2001, now U.S. Pat. No. 7,340,506, which was a continuation-in-part of application Ser. No. 08/879,958 filed Jun. 20, 1997, now U.S. Pat. No. 5,987,500 which was a divisional of application Ser. No. 08/700,726 filed Aug. 5, 1996, now U.S. Pat. No. 5,778,178 which was related to and claimed priority from U.S. provisional patent application No. 60/006,634 filed Nov. 13, 1995. This application is related to and claims priority from U.S. provisional patent application No. 60/206,422 filed May 23, 2000, application Ser. Nos. 09/792,323;08/879,958; 08/700,726; 60/006,634; and 60/206,422 are hereby incorporated by reference. U.S. Pat. Nos. 5,987,500; 5,778,178, 7,340,506 and sister U.S. Pat. No. 6,212,556 are also hereby incorporated by reference.
Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
1. Field of the Invention
The invention relates generally to performing transactions on a network. More particularly, the invention relates to a system and method for controlling a transaction involving multiple service providers.
2. Background Information
The Internet and the World Wide Web, hereinafter referred to as the web, provide a viable medium for electronic commerce and on-line services, however current systems and methods for using the Internet and the Web are extremely limited. In particular, current uses are limited to either browse-only interactions or simple "deferred" purchases involving a single service provider.
Alternatively, the user 105 may make a limited, deferred purchase of a car from the car dealer 150 and involving only the car dealer 150. For example, the user 105 may fill out a form on car dealer web page 160 and email the form to car dealer web server 155. After receiving the form, the car dealer web server 155 may perform some processing of the form, and then send it through a gateway 170 towards applications 175 that perform further purchase processing and read and write data 180 such as to a legacy database. The applications 175 and the data 180 are not directly connected to the Internet or the web and are not available to other entities connected to the Internet. Typically, the car dealer 150 alone may access the applications 175 and the data 180, and typically this is via a complicated and customized procedure. The actual purchase is deferred until the email is received, read by a person or system, and purchase processing is performed by a person or the applications 175 and data 180. Thus, the purchase is not performed in real-time and involves only the car dealer 150.
The user 105 may also select a bank hyperlink 165 embedded in web page 160. The bank hyperlink 165 causes the web browser 110 to connect to bank web server 192 presenting bank web page 194 via hyperlink address 165. This may allow the user 105 to browse bank web page 192 to obtain information about obtaining a loan, however, the association between the car dealer 150 and the bank 190 is a limited one involving the car dealer 150 only providing easy access to bank information via the bank hyperlink 165. Unfortunately, there is no cooperation or interaction between the car dealer 150 and the bank 190 besides the hyperlink 165. In fact, the hyperlink 165 disconnects the user from car dealer web server 155 and web page 160 and connects the user with bank web server 192 and bank web page 194. This lack of cooperation, control, and interaction greatly limits the services that may be provided by the web.
However, the CGI interaction is severely limited because each CGI application must be customized for a particular type of application or service. That is, different CGI application would have to be created for each service provided by the bank. For this reason, creating and managing individual CGI scripts for each service is not a viable solution for merchants with a large number of services.
As the Web expands and electronic commerce becomes more desirable, the need increases for robust, real-time, bi-directional transactional capabilities on the Web. A true real-time, bi-directional transaction would allow a user to connect to a variety of services on the web, and perform real-time transactions on those services. For example, although user 100 can browse car dealer Web page 105 today, the user cannot purchase the car, negotiate a car loan or perform other types of real-time, two-way transactions that he can perform with a live salesperson at the car dealership.
Ideally, user 100 in
In order to provide sophisticated and useful services over the web, it is desirable to control and manage cooperation and interaction among a plurality of service providers that each contribute to the transaction. This goal is constrained by the prior art systems and methods for using the Internet, which do not control or manage multi-service provider transactions and which do not permit sophisticated and useful joint service offerings.
The novel features believed characteristic of the invention are set forth in the appended claims. The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements. The invention itself, however, as well as a preferred mode of use, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings:
A method and apparatus are described for performing transactions involving multiple service providers over a service network. Broadly stated, embodiments of the present invention seek to maintain control over the transaction including controllably and selectively routing to and involving service providers in the transaction. According to one embodiment, this may include a network transactional application including control and routing software objects and distributed remote software objects to interface with the network transactional application and perform controlled transactions. Advantageously, this may allow sophisticated, real-time, multi-service provider transactions to be performed while allowing one entity (e.g., a context owner) to control the transaction.
In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.
The client access device 310 may access the facilities network and the service network via server "switching" sites or corresponding appropriate non-web switching sites such as cellular provider sites. For example, a cell phone may access a cell site where resides a computer system having an IP address and a functional connection to a hub either on that computer system or on a connected computer system.
The facilities network may be any suitable facilities network or combination of potentially heterogeneous facilities networks, including an IP-based network, a TCP/IP-based network, the Internet, the web, a non-web network, an email network, Integrated Services Digital Network (ISDN), Asynchronous Transfer Mode (ATM), Personal Communications Services (PCS), X.25, Ethernet, frame relay, token ring, Fiber Distributed Data Interface (FDDI), Community Antenna TV (CATV), an intelligent network, a public-switched network, a public-switched telephone network, a plain old telephone system (POTS) network, a private switched network, a wireless network, a cellular network, private/leased lines, an intranet, a private enterprise network, or another network suitable for supporting a service network such as those described in the present specification. For example, the client access device 310 may connect to the facilities network via a wire, cable, cellular, or PCS connection, service provider 1 360 may connect via a T1 connection, service provider N 380 may connect via a T3 connection, and service provider N 380 may additionally have an ATM/Sonet or Frame Relay/T3 connection to a branch office to perform processing.
The service network processing 350 is functionally interposed between the client access device 310 and multiple service providers and associated software that provides services to the client access device 310. According to one embodiment, the service network processing 350 provides a network transactional application that provides an overlay service network that operates on and runs on the facilities network 320. The network transactional application may provide the service network according to an N-tier manager-agent model that achieves N-way communication by using a value-added network (VAN) switch or object router that resides at the transaction network entry point to route to software residing at remote service provider nodes. The network application may use an N-way interactive object router to provide the link between the clients and the service providers. The service network may provide access to a myriad of network services such as selling of products (e.g., books) and services (e.g., shipping, pizzas delivery), banking, trading (e.g., stocks), advertising, customer service, bill management, and others.
The service network processing 350 may include transactional control and management software to control and manage one or more transactions involving the client access device 310 and any number of service providers that are desired for the particular transaction. Control and management may include establishing a connection or link (e.g., a line, channel, or thread over which data may be communicated) to service providers, making requests, activating or configuring transactional applications, receiving results, de-establishing connections with service providers, fault-handling, monitoring performance, monitoring transactions, monitoring client activity and service provider activity (e.g., to support accounting and billing policies of the service network), collecting statistics, security processing, address processing to uniquely address and identify network locations and objects by a unique network address, routing processing to uniquely identify, retrieve, and route dynamically changing information and software objects using multi-media, object routing, and others. According to one embodiment, management includes distributed control of Events, Configuration, Accounting, Performance, and Security (ECAPS). By way of example, events may include responding to specific occurrences on the network, configuration may include managing the connections that exist within the network, accounting may include measuring and recording network transaction activities, performance may include monitoring and maintaining network performance standards, and security may include enabling connection and transaction privacy.
The service network processing 350 may support industry-standard web browsers (e.g., Internet Explorer available from Microsoft Corporation of Redmond Wash.), web servers, security protocols, and connect to applications and middleware, including both legacy and relational database management systems (RDBMSs). In an embodiment where the service network 350 operates over the Internet, the service network 350 may comply with open Internet standards and protocols.
According to various embodiments, the network processing 350 may be distributed between a hub and a plurality of nodes each associated with a service provider. The term "hub" will broadly be used to refer to one or more functionally coupled computer systems (e.g., a web server server) that provide software and methods to control a transaction or service involving multiple service providers. The hub may be considered as a portal or gateway into the service network that provides selective and controlled access into the service network to computer systems and methods associated with service providers of the network. The term "node" will broadly be used to refer to one or more functionally coupled computer systems that provide service methods under the control of the hub. Thus, the service network 350 may extend to software, objects, and methods at the service providers 360, 370, and 380, as will be explained in more detail elsewhere. According to one embodiment, links from the client access device 310 to such software, objects, and methods is via the hub.
According to certain embodiments the hub includes a router to route to and establish links to software objects at nodes. The term "router" will broadly be used to refer to software to create or allow a link to potentially remote and geographically distributed software. In one embodiment, the router is an object router that uses objects and class information rather than unrelated functions and data. For example, in one specific embodiment, the object router provides two types of a class, namely a skeleton that is the functionality of the object and its stub that allows remote access to the same object. Typically the stub is located on one computer system, such as a client computer system or a hub computer system and the skeleton is located on a different remote and geographically distributed computer system associated with a service provider, a user to specify functions to be executed remotely. According to one embodiment, the object router is part of a value-added network transactional application and resides at the network entry point (e.g., the hub) to provide an N-way interactive link to other software that resides at remote and geographically distributed IP nodes. Specific exemplary embodiments of hubs, nodes, routers, object routers, and objects will be discussed elsewhere, although other embodiments are contemplated.
The term "service provider" will be broadly used to refer to a network-connected entity or presence, such as a business, merchant, organization, administration, networked user, or other provider that provides or participates in a service associated with the service network. Typically, the service provider participates in joint services involving multiple service providers. The multiple service providers may include a service provider 1 360, a service provider N 380, and optionally any number of additional service providers 370. Accordingly, the total of service providers may be any integer number of service providers. The service providers 360, 380 may be any service providers suitable for the intended service network, including merchants and businesses that desire to provide their products and/or services to a client associated with the client access device 310. For example, the service providers may be businesses that provide web servers, web pages, transactional applications to sell products or services, and data to facilitate the transaction. The multiple service providers may also include other client access devices similar to client access device 310. For example, client access device 310 may obtain services that involve other client access devices, such as in a service network incorporating features similar to those in an interactive chat or messaging, an online bartering, an online file-sharing, or other services. The service providers are to be interpreted broadly in the present application and many exemplary service providers will be discussed in the specification, although others are contemplated.
After accessing the facilities network, the client access device 410 may access or utilize the service network 435. This may be done in a way compatible with the client access device 410 and the service network 435. For example, a web browser access device 411 may request to access the service network to obtain one or more services by communicating a request to connect to a web server and web page based on data input into a computer system by a client or user. Alternatively, a cell phone access device 412 may access the service network by entering a phone number associated with the service network 435 into the cell phone access device 412, which automatically connects to the facilities network 420 and the service network 435, which may be a call center providing interactive voice response (IVR).
The service network 435 may selectively and controllably manage the connection to and use of service provider hardware and software 440, which may be by direct connection 450 or by indirect connection 460 with the service network 435. As shown, applications 451, middleware 452, 4GL applications 453, operating systems 454, and hardware 455 may be directly connected to the service network 450. Typically data 462 (e.g., enterprise data), host TP applications 464, and other hardware 466 (e.g., printers, faxes, etc.) will be indirectly connected to the service network 460, such as via the applications 451, or middleware 452.
Without loss of generality to other services and transactions, and to illustrate the advantages provided by the service network, consider an exemplary multi-provider service involving a client access device 510 purchasing a car from car dealer presence 520 by obtaining a loan for the amount of the car from bank presence 530 and insurance for the car from insurance provider 540. The client access device 510 first determines the amount of the car from car dealer presence 520 and indicates a desire to purchase the car for the amount by obtaining a loan from bank presence 530.
Then, the service network automatically establishes a controlled link 560 with bank presence 530. Advantageously, this may be done without losing connection to and communication with car dealer presence 520. Then, bank presence 530 establishes a controlled link 555 with access device 510 to obtain data to process the loan. After bank presence 530 approves the loan it may verify the loan to the client via controlled link 555 and to the car dealer presence 520 via controlled link 560.
The car dealer presence 520 may then connect with an insurance provider 540 via controlled link 565 to advertise an insurance policy to client access device 510 via controlled link 575 and receive an acceptance of the policy via controlled link 575. The insurance provider 540 after processing the insurance policy may provide verification to the client via controlled link 575 and to the car dealer presence via controlled link 565. The car dealer presence 520 may then send a complete transaction verification and summary to the client access device 510 via controlled link 550 to finalize the particular transaction.
As discussed, the transaction involves interactions between the client access device 510 and multiple service providers 520, 530, 540 under the control of the service network. Advantageously, this allows collaborative and cooperative transactions and interactions that are not possible in prior art approaches. In this way, transactions are not limited to two-way transactions involving a client access device and a single service provider, but are flexible to include three-way, four-way, or N-way transactions and interactions involving any desired number of service providers and the client access device. According to one aspect of the present invention, predetermined strategies involving collaboration and cooperation among service providers may be devised to incorporate N service providers, where N is any desired integer number of service providers that have agreed to collaborate and cooperate to provide the services. Thus, according to one embodiment, the service network may allow for service transactions involving "any-to-any" communication and interaction, thus facilitating a large, flexible variety of robust, real-time transactions on the network.
The network entry point 620 allows connection with a hub 630. The hub 630 may serve as a service network control center or network operator to configure, provision, control and manage access to and services provided by multiple potentially geographically distributed service nodes that provide networked services to clients or subscribers. Advantageously, this allows control and customization of the class and level of service provided over the network by the service control nodes.
Typically, the hub 630 includes software to control and manage transactions over the service network. According to one embodiment, the hub may assist with providing the network entry point 620 and access to point-of-service applications by providing software such as Java applets or ActiveX controls. The hub 630 may also include multi-protocol value-added network switching software to switch between remote service provider nodes and routing software to perform controlled routing electronic transactional documents, components, objects, or data, in a form that may be received and interpreted by computer systems, applications, hardware, and other networked components associated with the service providers. The hub 630 may also track and store data such as transaction statistics.
The hub 630 may access a plurality of nodes 640. As shown, the plurality of nodes include a node 1 650, a node 2, optionally any desired number of additional nodes 670, and a node N 680. The node N 680 may represent any desired number of nodes. Typically, each node will be associated with at least one service provider. In one case, a service provider may provide its services through a logical plurality of nodes based on access device, service or product offering, other service providers, and for other reasons. By way of example, a service provider may provide one node for web-based access, one node for cellular access, one node for each major service or product line, one node for business partners, one node for employees, and for other reasons. Additionally, multiple service providers may share a common node. For example, the car dealer and the bank may decide to share a common node.
Each node may serve as a gateway, portal, or entry point into a private or enterprise network of the service provider. The node may provide selective access to service related resources of the service provider such as applications, data, hardware, personal, and other resources. The node may act as a service agent and management station for the service provider. It may also provide a channel interface to back-office transaction processing applications.
According to one embodiment, the hub 630 and the nodes 640 contain software to control and manage a plurality of distributed service and application software objects or components. The term "objects" will be used to refer to separable software objects capable of being distributed over a network and operated remotely. The objects may be object-oriented software objects based on object class. They may be objects conforming to standards and models, such as the Component Object Model (COM), Object Linking and Embedding (OLE), ActiveX, Distributed COM (DCOM), System Object Model (SOM), Distributed SOM (DSOM), Common Object Request Broker Architecture (CORBA), Distributed interNet Applications Architecture (DNA), COM+, Java-based components, and others. For purposes of illustration, and without limitation, a COM object may have a "published" unvarying interface that exposes its service or business functionalities and the parameters it accepts, and the COM object may be accessed in a distributed computing environment by a COM-compliant service application to use its functionalities to deliver services or transactions to a client. Thus, the hub 630 and/or the nodes 640 may provide "component-oriented middleware" that controls and manages potentially distributed components to create distributed applications and provide the service network. The middleware may include management instructions to use the components to deal with transactions, component packaging, and state management. Typically, the hub 630 will contain software to intelligently switch to, route to, configure, provision, track, manage, and control the objects or components. Such an architecture may be well suited to a high throughput transactional environment.
According to one embodiment, the node uses an intelligent state management engine such as a Distributed Online Service Information Base (DOLSIB) to store and access transaction management information. DOLSIBs will be described in more detail elsewhere in the specification. The node may use the intelligent state management engine or DOLSIB to automatically create the associations between the clients screen elements and the service objects routed to the service control nodes. Each node may have a separate DOLSIB, according to one embodiment.
According to one embodiment, software for the hubs and nodes may be provided as shrink-wrapped software packages. The context owners and service providers may then obtain these software packages, input business and management objects into the DOLSIB, and create or join service networks.
Context Owners
According to one embodiment, a context owner may provide the hub. The term "context owner" will be used to refer to a service provider that provides a service network of other service providers. In one case, the context owner may use the hub and nodes to provide a virtual private network of itself and other service providers that provide an end-to-end value-added service or transaction. In this case, the hub may be located at the context owners web server, web site, or call center and the nodes may be located at the entry point into private enterprise networks of the other service providers. Advantageously, context providers may use the distributed control and management provided by the hub and nodes to provide control and management-added value to their service offerings.
Another type of context provider provides a service network of predetermined service providers associated with a multitude of transactional and service categories, any one of which may be selected and performed on the service network. For example, the context owner may be a dynamic yellow page provider resembling a search engine with the additional advantageous capability of being able to initiate a service transaction based on a search and involve a plurality of additional predetermined service providers in the transaction to add overall value to the transaction. In this way, a user of the dynamic transactional yellow pages may search for car dealers using the dynamic transactional yellow pages (e.g., search engine), locate a predetermined car dealer of the service network, be automatically connected with one of another predetermined banks of the service network, and be connected with a selectable one of another predetermined number of insurance providers of the service network.
Alternatively, the context owner may be another context owner, such as a network service operators (e.g., AT&T, Sprint, MCI), an Internet service provider (e.g., AOL, UUNet, Netcom, PSINet), a portals (e.g., AOL, Yahoo!, CNET, enterprise portals), a virtual malls (e.g., Priceline, Shop@aol, ToysRUs.com), an e-marketplaces (e.g., Commerce One, Ariba), a direct merchant service (e.g., Bank of America, Fidelity, Vanguard, LL Bean, Amazon.com), an ASP (e.g., MGM/Blockbuster), an Internet brokerage firm (e.g., E*trade, Fidelity Investments), an extranet context owner (e.g., insurance industry, underwriters), an intranet context owner (e.g., a payroll processing center for a Fortune 1000 company connecting multiple departments and banks for timecard input, payroll deductions/withholding adjustments), a search engine (e.g., Yahoo!), and others.
Establishing the links 750, 770 are done under the control and management of the hub 740. This compares favorably with prior art approaches which provide hyperlinking and which would not be able to achieve centralized control and management of the service experience of the client access device. Advantageously, in this way, the client access devices service experience may be less like a visitor-center-type experience, such as through yellow pages or a search engine, in which the client is informed of a site and sent away to that site with loss of control over, and more like a supermarket-type experience in which control over the service experience of the client has not been lost, and the service control of the client may be managed, controlled, tracked, and otherwise improved.
The method 900 commences at block 910, and then proceeds to block 920, where a service network is accessed via a network entry point. According to one embodiment, a user connects to a web server (or a call center or cell site) running an exchange component, the user issues a request for a transactional application, the web server hands off the request to the exchange, the exchange activates a graphical user interface (GUI) to present user with a list of Point-of-Service (POSvc) transactional applications, and the user makes a selection from the POSvc application list. POSvc applications are transactional or service applications that are designed to incorporate and take advantage of the capabilities provided by the present invention.
The method 900 advances from block 920 to block 930, where switching to a transactional application is performed. Switching may include value-added network switching to local applications or components or remote applications or components and causing routing to those applications or components. Switching may also include flow control, prioritization of requests, and multiplexing. According to one embodiment, interconnected OSI model application layer software switches may perform the switching.
The method 900 advances from block 930 to block 940, where a route to a node is performed under the control of the hub. Routing may include performing multi-protocol routing to remote components or applications by using Simple Network Management Protocol (SNMP), TransWeb™ Management Protocol (TMP), or others. Traditional security features (e.g., RSA, SET1, SET2), and others are contemplated.
The method 900 advances from block 940 to block 950, where transaction processing is performed. This may include retrieving data from a data repository, such as by using TMP or another protocol.
A determination is made at decision block 960 whether another node is involved in the service. As stated above, the determination may include querying and receiving a response from the client and/or receiving an indication that another node is involved based on the prior transaction processing at block 950 and/or others. If yes is the determination 962 then processing loops through blocks 940-960 until no is the determination. Routing to the other nodes may be done with control and while keeping the previous nodes involved in the transaction if they still have an interest in the transaction.
If no is the determination 964 then processing advances from decision block 960 to block 970 where transaction results are provided. The method 900 terminates at block 980.
Together, the web server 1020, the exchange 1030, and the operator agent 1040 provide a web page 1050, one or more point-of-service (POSvc) applications 1060, VAN switch 1070, and object router 1080. According to one embodiment, the exchange 1030 displays an web page 1050 in the web browser 1010 including the list of POSvc applications 1060 that are accessible to the exchange 1030. A POSvc application is an application that can execute the type of service or transaction that the user may be interested in performing. By way of example, the list of one or more POSvc applications may be displayed in an HyperText Markup Language (HTML) GUI, a Virtual Reality Markup Language (VRML) GUI, a Java GUI, or another GUI.
Depending on the particular implementation, although they are shown as separate entities, the VAN switch 1070 and the router 1080 may be combined to form a router to provide multi-protocol object routing. In one embodiment, this multi-protocol object routing is provided via TransWeb™ Management Protocol (TMP), available from WebXchange Inc. of Scotts Valley Calif., which may incorporate traditional security features (e.g., RSA, SET1, SET2, etc.). Alternatively, routing may be done using Simple Network Management Protocol (SNMP).
One embodiment of the present invention utilizes network accessible virtual information stores to perform routing. In one case, the virtual information stores are distributed on-line service information bases (DOLSIBS). Information entries and attributes in a DOLSIB virtual information store are associated with a networked object or component identity. The networked object identity identifies the information entries and attributes in the DOLSIB as individual networked objects, and each networked object is assigned a network reachable address (e.g., an Internet address). For example, the Internet address may be assigned based on the IP address of the node at which the networked object resides. Routing may be done using the DOLSIB and TMP or another protocol. In one case, TMP and a DOLSIB may be combined with Secure Sockets Layer (SSL), s-HTTP, Java, a component model (e.g., DCOM), the WinSock API, object request broker (ORB), or another object network layer to perform and manage object routing.
The VAN switch 1070 and object router 1080 will be described elsewhere in the specification. Thus, according to one embodiment, the exchange 1030 and an operator agent 1040, described in more detail elsewhere together perform the switching, object routing, application and service management functions according to one embodiment of the present invention.
The network or Internet address for each networked object essentially establishes the networked object as an accessible or "IP-reachable" node on the network or Internet. These network addresses may be used to represent the objects in a DOLSIB. For example, the network address 188.8.131.52.1 may be used to represent object 1 in the DOLSIB. The DOLSIB may also contain a along with a name, a syntax, and an encoding. The name is an administratively assigned object ID specifying an object type. The object type together with the object instance serves to uniquely identify a specific instantiation of the object. For example, if an object is information about models of cars, then one instance of that object would provide a user with information about a specific model of the car while another instance would provide information about a different model of the car. The syntax of an object type defines the abstract data structure corresponding to that object type. Encoding of objects defines how the object is represented by the object type syntax while being transmitted over the network. Then, TMP or another protocol may be used to uniquely identify and access these objects from the web server node, based on the network addresses recorded in the DOLSIB.
To perform a service transaction that may be requested or indicated in a communication with the client access device 1205, the hub 1210 controllably connects with service provider node 1215. In this example, service provider node 1215 is a supplier selling products over the service network. The client access device 1205 indicates to purchase one model r100 at a cost of $100. The supplier 1215 connects and communicates with data source 1220 to obtain inventory data and update the inventory to reflect the purchase of one model R100 unit at a cost of $100. Arrow 1221 is partly filled to indicate that the requested model 100 is in inventory and was purchased. Status window 1222 indicates the purchase. A verified degree of completion of the service transaction is indicated by the difference in shading between arrows 1211 and 1223.
The hub 1210 determines that the purchasing portion of the service transaction has been verified completed and controllably connects with service provider node 1225, which in this example is a Visa node to bill payment to a Visa credit card account indicated by the client access device 1205. The Visa node 1225 communicates with data source 1230 based on, for example, a credit card number, to perform billing processing. Status window 1232 shows the billing. Completion of the billing portion of the service transaction is indicated by the difference in shading between arrows 1224 and 1233.
The hub 1210 determines that the billing portion of the service transaction has been verified completed and controllably connects with service provider node 1235, which in this example is a FedEx node 1235 to arrange delivery of the model R100. The FedEx node 1235 interacts with a data source 1240, based on delivery preference data supplied by the client access device 1205, to arrange delivery. Completion of the delivery portion of the service transaction is indicated by arrow 1243, which is entirely filled.
The hub 1210 determines that the purchasing, billing, and delivery portions of the service transaction are verified completed, as indicated in the status window 1245, and provides confirmation of the service transaction to the client access device 1205, as indicated in status window 1250. Advantageously, the transactional control provided by the hub 1210 has allowed a multi-service provider value-added service to be provided to the client access device 1205, including verification of multiple transactional portions of the service. According to one embodiment, the hub 1210 is financially compensated by the nodes 1215, 1225, and 1235 based on a visit or hop to the node, a purchase, a purchase amount, and according to other desired criteria.
Physical layer 1301 may transmit unstructured bits across a link. Data link layer may transmit chunks across the link and may perform check-summing to detect data corruption, orderly coordination of the use of shared media, and addressing when multiple systems are reachable. Network bridges may operate within data link layer 1302. Network layer 1303 may enables any pair of systems in the network to communicate with each other. Network layer 1303 may contain hardware units such as routers to handle routing, packet fragmentation, and reassembly of packets. Transport layer 1304 may establish a reliable communication stream between a pair of systems and deal with errors such as lost packets, duplicate packets, packet reordering and fragmentation. Session layer 1305 may offer services above the simple communication stream provided by transport layer 1304. These services may include dialog control and chaining. Presentation layer 1306 may provide a means by which OSI compliant applications can agree on representations for data.
The application layer 1307 typically defines the language and syntax that applications use to communicate. Application layer 1307 may provide a means for application programs to access the OSI environment. By way of example, an application on one computer system in a network uses application-layer prescribed commands to access or request data from an application located on another computer system of the network. Often the application layer 1307 is responsible for functions such as file management (e.g., opening, closing, reading and writing files), transferring files, transferring messages (e.g., email messages), executing jobs remotely, obtaining directory information about network computer systems, and other distributed computing applications. Application layer 1307 may include services such as file transfer, access and management services (FTAM), electronic mail and virtual terminal (VT) services.
According to one embodiment, the invention uses software conforming to the application layer 1307 of the OSI model to provide the service network by providing communication, control, and management of distributed software. For example, according to one embodiment, the routing switch is implemented to function within the application layer 1307 of the OSI model. Application layer routing may create an open channel for the management and the selective flow of data from remote databases on a network.
Boundary service 1410 may provide the interface between VAN switch 1400 and a facilities network and client access devices. Boundary service 1410 may also provide an interface to an on-line service provider. Using these interfaces, a client may use a client access device to connect to a local application, namely one accessible via a local VAN switch, or be routed or "switched" to an application accessible via a remote VAN switch.
Switching service 1420 may perform a number of tasks including routing user connections to remote VAN switches, flow control, prioritization of requests, and multiplexing. Switching service 1420 may also facilitate open systems' connectivity with both the Internet (a public switched network) and private networks including back office networks, such as banking networks. Often, the switching service represents a core of the VAN switch 1400. According to one embodiment, the switching service 1420 is implemented as an OSI application layer switch.
Management service 1430 may contain tools that are used, such as by end users, to manage network resources including VAN switches like VAN switch 1400. For example, the tools may include Information Management Services (IMS) and application Network Management Services (NMS). Management service 1430 may also provide Operations, Administration, Maintenance & Provisioning (OAM&P) functions. For example, the functions may include security management, fault management, configuration management, performance management and billing management for the service network. Network management, such as provided by management service 1430, is another significant aspect of certain embodiments of the invention and may be used to add quality and value to the services provided.
Application service 1440 may contain application programs that provide customer services. For example, application service 1440 may include POSvc applications such as those discussed in
An object router may be used to controllably route to networked entities such as computer systems, applications, objects, and data. The object router may allow for the transparent completion of service transactions involving distributed applications and software components without the programmer needing to know whether networked entities are local or remote. The router may be able to automatically determine this, such as based on looking up a network address of a relevant entity and using correct operations compatible with the type of entity. An object router may include a library to provide support for the application programming interfaces (APIs) to remotely access an object, its data, and its functions in an object network. This interface may provide a skeleton class to contain the functionality of the object and corresponding or counterpart stub class to allow remote access of the object. A stub and a skeleton may be functionally coupled together. For example, a stub may be installed on a client computer system and a corresponding skeleton installed on a server computer system and in combination they interoperate to allow a remote procedure or method call. In one case the stub may declare itself and its parameters. Arguments to the function may be specified in a meta file and a type of the argument may be specified by value or by reference. The object router may allow for new data types to be constructed, using the basic data types of the programming language used in the particular embodiment: int and String. Single simple inheritance classes may be constructed and then used as data members or pointer within another meta class. Typically, the router will be implemented in a programming environment and language that is object-oriented and allows for distributed computing, such as C++, Java, and a component model. However other embodiments are also contemplated.
Before continuing with the detailed explanation of the present invention and various exemplary embodiments of the present invention, it may be helpful to briefly explain some terms, without limitation, that will be used in the discussion below. These explanations are provided to facilitate understanding of the following text, rather than to limit the invention. The term "abstract class" will be used to refer to a C++ class that does not have all virtual functions defined. The term "class" will be used to refer to typically a C++/Java data structure definition that defines both the data and the functions. The term "interface" is a Java term similar to the C++ abstract class. A "meta-compiler" translates a higher-level "meta-language" (e.g., WebX, available from WebXchange) from the "meta-file" into a lower-level language (e.g., C++) output file for and before giving to a traditional compiler. The software may be compiled under a version of Windows NT using a Microsoft Visual C++ version compiler based on the wx.lib and the Rogue Wave libraries, available from Rogue Wave of XXX, XXX, Tools++, Net++ and Threads++. Other software platforms are contemplated. The term "object" may be used to refer to a C++/Java data structure instance that is defined by a class.
A meta compiler 1680 may be provided for use with the layers 1660 and 1680 The meta compiler 1680 will be used broadly to refer to an automated mechanism to code features based on structured typically concise definitions. For example, the meta compiler 1680 may take a definition file and substantially automatically create the object identity, data serialization, data marshaling, string execution, abstract base class, and the stub/skeleton multiple inheritance. Advantageously, such automated coding may improve the efficiency of the implementation and may reduce errors. Of course, coding may be performed manually without such a meta compiler, although such implementations are expected to be more laborious, expensive, and prone to error.
The meta compiler 1680 may use a Tool Command Language (TCL) program or a similar program or encoding. TCL is an interpreted script language that may be used to develop applications such as GUIs, prototypes, CGI scripts, and others. TCL may provide an interface into C, C++, and other compiled applications. The application is compiled with TCL functions, which provide a bi-directional path between TCL scripts and the executable programs. TCL provides a way to "glue" program modules together. TCL may also come as TCL/TookKit (TCL/Tk), which provides a GUI toolkit to create GUIs. Scheme, Perl, and Python have incorporated elements of TCL/Tk. According to one embodiment, the meta compiler 1680 is the rme2c meta compiler discussed elsewhere in the present application.
In one embodiment, the meta compiler is run by the command rme2c<classname>, where the classname is the base class (e.g., Account). The Account.rme file as well as other parent definitions should desirably be in the same directory. The object router TCL files are found under Wx/Util. These files parse the description file and produce the six C++ output files. Often, the syntax of the meta compiler should be adhered to closely. Blank lines and lines beginning with a pound sign "#" are considered comments. The following words may be reserved:
With reference to
A detailed discussion of an exemplary object router is provided without limitation to further illustrate operation of an object router according to certain embodiments. In the following discussion, the reader is respectfully directed to FIGS. 18 and 21-22 and associated text for further illustration and discussion of the characteristics and structure of the classes and objects used by the exemplary object router.
The object router typically includes functionality to determine an object identity for a networked object in order to communicate with the object. The identity may be determined from a library that stores identities for many such networked objects. In one case, the object identity may be determined by using a WxObject in a wx.lib library. In such a case each new class "XYZ" may add a XYZ_ClassID, XYZStub_ClassID and XYZSkel_ClassID to the Wx/ClassID.h file. Based on the object identity, the object router may transparently determine whether the object is local (e.g., a skeleton on a server) or remote (e.g., a stub on a client or an object on another server). The object router may also determine the argument parameters and object serialization.
The object router typically uses some protocol to communicate with remote computer systems and software. Communicating may include transferring objects, parameters, and data. Often a network line protocol/TCP will be used. The WxRemotePDU shown in
The object router may also perform data marshalling. Data marshalling may include checking parameters that are passed as arguments to methods to determine if any parameters are missing or wrong, and may include throwing an exception or otherwise signaling if a parameter is missing or wrong. This may be provided by a meta compiler in the stub and skeleton.
The object router may block a thread during network transmission and reception by using a different thread to perform the actual network activity and control the calling thread status. Advantageously, this may allow a remote object to be called similarly to a local object. In one case, a Rogue Wave RWCondition class in the WxRemotePDU class may perform this function.
The object router may use string execution to allow an ASCII string representation to call a method. This may provide a useful, simple, and unique means of calling a class method that may also be used directly by a programmer. A meta compiler in the base class may create this data marshalling.
The object router may also perform reference counting on local and/or remote objects. This may avoid time consuming malloc's, free's, and confusing details of which function is responsible for deleting which object. The object router may use such reference counting to deal with WxRemoteObject types. The programmer may also use reference counting. Typically, a WxRemoteObject child should not be destroyed using delete, and an exception may be thrown if this is tried, but rather the WxRemoteObject child should be destroyed by using the member function ol_unreference( ). Also, if a user stores a copy of a WxRemoteObject child, the method ol_reference( ) should be called to prevent the object from being destroyed by some other user or method. WxRemoteObjectInt may provide this interface.
The object router may use an abstract base class and multiple inheritance according to certain embodiments. Advantageously, the abstract base class may allow interaction with a local or remote object without knowing its location. This base class may be the parent of both the stub and the skeleton, which may be inherited from the abstract base class and from their respective object layer classes. This allows them to inherit the functionality of the base class as well as the object layer routines. Often, the inheritance will be provided by the meta compiler.
The object router may also include at least an interface to a user-defined data model to provide a basis of the object layer to the next level up the software layers. The user-defined data model may include a set of user-created classes built around and on top of the object router APIs. This foundation appears local to the programmers using the object layer even though it may be remote.
The object model 1700 comprises base classes WxObject and WxRemoteObjectInt from which other classes and objects derive. The derived components are either object layer objects 1720 (e.g., Object, WxRemoteObject, WxReference, WxRemoteSkel, WxRemoteStub) or data model objects 1740 (e.g., WxName, WxNameStub, and WxNameSkel).
A programmer that is creating transactional objects is likely to work closely with the base class WxRemoteObject and/or WxRemoteObjectInt. WxRemoteObjectInt is an abstract base class that may contain all of the member methods and data access components as well as support functions to provide a uniform interface to behave as a WxRemoteObject. For example, this may include (a) WxStringExecution to execute any method using a simple ASCII string and object type data, (b) WxLock to provide a thread synchronization mechanism, (c) WxFlags to provide a simple and consistent Boolean flag variable, (d) reference counts to allow sharing and manage ownership concerns, (e) conversions between OBJECT, WxRemoteReference, WxRemoteStub and WxRemoteSkel types, and others as desired. As shown, both the object layer objects 1720 and the data model objects 1740 inherit an interface specification WxRemoteObjectInt.
WxName is a new data model object 1740 that contains one data member "name" which is a string. The meta compiler may automatically create two access components for this data member, namely Get_Name and Set_Name. The meta compiler may also create the server and client versions of this data object.
Typically the skeleton is used to represent the server side of the object router. For example, WxNameSkel is a class that is derived off the abstract base class WxName and WxRemoteSkel. Often the programmer defines or customizes the methods, except for the data access components, for the skeleton, since this is the actual object embodying the business or transactional methods. Real instances of the class may be created with the suffix "skel".
The stub represents the client or remote side of an object for the object router. As with the skeleton, the stub too is derived off the abstract base class WxName and an object layer class WxRemoteStub. Typically, the meta compiler will generate all methods for the stub.
Without limitation, the use of certain conventions and codes (e.g., prefixes, suffixes, etc.) may be used to improve certain implementations. A partial list of exemplary conventions and codes is provided below. Those having an ordinary level of skill in the art will appreciate that the exemplary conventions and codes are not needed to implement the invention. They will also appreciate that numerous other conventions and codes may be conceived to improve certain other aspects.
In response to the selection, the web server 1810 starts an applet 1820 that runs in the web browser 1805. The applet 1820 registers with the object router. The object router may determine the identification and network location of one or more objects associated with the transaction. The object router may assist with creating stub 1830 on a computer system 1825, which may be the computer system running the browser 1805 or another computer system. According to one embodiment, the computer system 1825 may be a hub.
Via the stub 1830 a connection is made to a server 1835 containing a skeleton object 1840 associated with the bank transaction. Thus, once the stub is received, the user can then look up bank accounts as if local to the skeleton on the server side. The skeleton object 1840 presents transactional data 1850 to the user. Often, the transactional data 1850 will include a field for data entry, such as the ID and Pin fields shown. The user may enter data into these data fields and return the entries to the skeleton 1840 via the stub 1830. Based on these entries the skeleton 1840 may perform transaction processing. Transaction processing may include connecting with other local objects such as a user-specific Bob's account object 1845 and non-user specific Joe's account object 1846. In this case, user-specific data may be obtained from Bob's account object 1845 and returned to the browser 1805 via the skeleton 1840 and stub 1830 as transaction data 1860 including deposit interaction field 1862 and withdraw field 1864.
A stub object 1865 associated with the transaction data 1860 may be established at the computer system 1825 to perform transactions associated with the interactions 1862 and 1864. The user may then enter an amount into deposit interaction 1862, which then activates a deposit of said amount into Bob's account object 1845 via object 1865. Of course, in other implementations this could be handled differently. For example, such operations could be performed by a stub 1830, which also includes the functionality described for stub 1865.
Advantageously, the user was able to receive controlled banking transaction processing. Other embodiments are contemplated, including more complicated and interactive single service provider transactions (e.g., in which more arrows are bi-directional) and involving multiple service providers. The later case of multiple service providers will be shown and described for
A programmer may begin by creating a definition file describing the WxBank and WxBankAcount objects. Typically this will be written in a simple language, such as TCL, which may be parsed by the rme2v meta compiler. For example, the WxBankAccount file may be written as:
This class may contain methods and data. In this case, the data may be an integer describing the amount of money the account holds. Deposit and withdraw methods may increment or decrement the integer amount as follows:
Notice that the programmer should provide thread locking. For example, by adding the statement, WriteLockGuard lock(wxlock( )) to each desired method. Note that when the method is locked, no other locked methods that include any object-layer defined data access components may be called. The above file (WxBankAccountSkel.cc) defines the skeleton methods. The stub methods are typically defined by the rme2c meta compiler.
The Bank.rme file may be represented by the following code:
This file, when processed by rme2c will create six files: WxBank.h, WxBank.cpp, WxBankStub.h WxBankStub.cpp, WxBankSkel.h and WxBankSkel.cpp. These six files describe the operation and remote execution of the WxBank object. Since there is no data, no data access components will be generated. The method "getaccount" is defined as follows: method const WxBankAccount* getaccount {int id} {mint pin}. The keyword "const" identifies that this method will not change the object data. The next keyword is the returned object "WxBankAccount*". The asterisk indicates that the object will be passed by reference. The "getaccount" is the actual method name. Two parameters of the method are provided next in braces. Each parameter is provided in braces with a data type followed by a parameter name. In this case there are two integer parameters with name id and pin.
The programmer may describe any additional functionality for the operation of this object and the definitions of the skeleton methods in the WxBankSkel.cc file. The WxBankSkel.cc file may contain:
This is a simple example in which getAccount returns Bob's account. Note that the actual method name is "getAccount_ref" with "ref" appended since this method will return an object by reference. Also, notice that before simply returning the global variable Bob, the reference count is incremented since getaccount is passing a new reference.
Typically the skeletons are created in the server side. Then the skeletons may be registered in the name server, as indicated by the following exemplary code:
The client may have the following exemplary code:
Advantageously, in this way the programmer does not have to know, nor care, whether the object "bob" is local or remote.
The hub 1904 includes a greeter 1915, which may be software or a dedicated server. In this case, the greeter 1906 contains a web page 1908 containing HTML code and an applet 1910. The web page 1908 presents a window 1912 in the browser client 1902 including text 1914 and a selection mechanism 1916 to indicate a particular transaction (e.g., in this case to purchase product 1).
In response to a selection of the mechanism 1916 the applet 1910 starts running in the client 1902 to present a transaction window 1918 and a VAN switch (not shown) may switch to a particular transactional application associated with the mechanism 1916. This may include registering with an object router 1920. The router 1920 may then route to a first node 1922 including a supplier object 1924 and a product object 1926 which may then return window 1928 including a cost $100 for product 1 and payment options including a mechanism 1930 to allow payment from a particular bank's bank account.
In response to selection of the mechanism 1930 the router 1920 routes to a second node 1940 including a bank object 1942 associated with the bank. The bank object 1942 returns a window 1946 including an ID entry mechanism 1948 and a Personal Identification Number (PIN) entry mechanism 1950.
In response to submission of a corresponding ID and PIN the object router 1920 routes to the bank object 1942 and an account object 1944 corresponding to the ID and PIN. The account object 1944 returns a window 1960 including account corresponding to the client of the ID and PIN including a balance of $4000 and an electronic payment option mechanism 1962.
An account stub 1964 may also be activated or transferred to the hub 1904 to correspond and interface to functions associated with the account object 1944. In response to selection of the payment option mechanism 1962 the account stub 1964, the account object 1944 and the supplier object 1924 may interact and process so that the purchase price of $100 for the product 1 is paid from an account of the client to an account of the supplier.
Numerous variations and alternative embodiments are also contemplated for a multi-service provider transaction. For example, several single-directional arrows have been shown for purposes of clarity, however any or all of these arrows could represent bi-directional communication. Additionally, certain objects (e.g., supplier object 1924 and product object 1926) could be combined, or further subdivided into additional objects. Accordingly, the example is to be viewed in an illustrative rather than a restrictive sense.
The first computer system 2015 may have a WXREMOTECLIENT object 2020 to request access into the service network. The second computer system 2065 may have a WxRemoteConnectionServer object to receive the request and serve as the entry point into the service network. This is an object of the main class of the server side of the object router. The WxRemoteConnectionServer then connects the WxRemoteClient with the WxRemoteServer. Then, the WxRemoteClient and WxRemoteServer may communicate by a TCP socket 2040. By way of analogy, this is similar to a person (WxRemoteClient) dialing up a telephone operator (WxRemoteConnectionServer) and the operator directing the call to the correct person (WxRemoteServer).
This is an interface typically included in all remote objects. The interface usually contains several abstract class definitions, including WxStringExecutionInt, WxLock and WxFlags. It may also define methods that are used by all or multiple remote objects.
RWBoolean ol_isValid( ) const
This may be tested if the programmer does not know if this object is local or if the connection is established. This will return TRUE if the object is local or it has a connection to the remote object.
unsigned get_ol_referenceCnt( ) const
This returns the number of pointers outstanding for this object. Typically, if garbage collection is enabled, this object will automatically be destroyed when the referenceCnt reaches zero.
WxReferenceId get_ol_referenceID( ) const
This is the remote referenceId for this object. This WxReferenceId uniquely tags an object instance on the server for the established connection. This is not a well-known name in the sense that it is not guaranteed to be the same with a difference connection.
Distributed Online Service Information Bases
Certain embodiments of the present invention may use a virtual information store suitable for a network. Without limitation, a specific type of virtual information store, referred to as a Dynamic Distributed Online Service Information Base (dynamic DOLSIB), will be discussed in greater detail. Other virtual information stores are contemplated.
The object router may use the dynamic DOLSIB to perform routing. For example, the object router may access the dynamic DOLSIB to obtain information about distributed software objects that has been recorded in the DOLSIB. Typically, the enterprise will be customized for each merchant. The following sections cover an overview of the architecture for the DOLSIB and a uniform interface that allows the service provider to provide a customized interface for the business objects using a simple Extended Finite State Machine (EFSM) or DOLSIB language. A library is also described that provides the core parser and interpreter for the DOLSIB. This library may also serve as the base class for business and management objects that will interface with the enterprise interface.
Before continuing with the detailed explanation of the present invention and various exemplary embodiments of the present invention, it may be helpful to briefly explain some terms, without limitation, that will be used in the discussion below. These explanations are provided to facilitate understanding of the following text, rather than to limit the invention. The term "state" will be used to refer to the set of values describing the current position of the machine if it has memory. The term "transition" will be used to refer to the action and state change performed by the machine after receiving an event. The term "event" will be used to refer to the inbound trigger that causes the machine to perform some transition. The term "action" will be used to refer to the output of the machine as a result of a transition. The term "diagram" will be used to refer to a complete finite state machine description containing states and transitions.
The architecture of a business object may at least conceptually comprise four parts, including: (1) the Extended Finite State Machine (EFSM) DOLSIB in the CoreBusinessObject or Management Object (C++), (2) the object router interface for the business or management object to the DOLSIB. (C++), (3) the enterprise interface protocol (specification), and (4) the DOLSIB instructions for the business or management object (EISM). The first part (DOLSIB and CoreBusinessObject or management object) may be built only once and may be part of the object router library. The second part may be built as a common business object and should be generic enough to be configurable for different merchants. The third part is a specification that may be written by the merchant for his own enterprise interface. The fourth part may be configurable during runtime for different business or management objects.
The following sections further discuss the DOLSIB, the language and grammar of the DOLSIB, and the CoreBusinessObject or management object. Specific examples, in this case banking examples, illustrate different service provider enterprise interfaces.
Typically a FSM has a finite set of states. An extended FSM does not have this limitation and may be used to provide a dynamic DOLSIB. Here the states are not finite, per se; there exists a number of finite state "blocks" on the diagram, but there are also global variables that may store values that take on an infinite number of possibilities. This adds another dimension to the FSM and makes the whole system have an infinite number of "states".
According to one embodiment, the Enterprise Interface State Machine (EISM) DOLSIB language may be a C-style DOLSIB EFSM language similar to ISO's Estelle. DOLSIB EISM is based on C style conventions, while Estelle is a Pascal language extension. The ISO Estelle language is defined as a superset of the Pascal language and fits nicely with the language. The DOLSIB EISM language is similar in that it conforms to the syntax of C. The DOLSIB EISM language may provide for more than one state machine diagram (and thus, more than one state machine) to be described and operated by the same script. The state machine may be interpreted allowing for bytecode compilation into a stack machine opcode. The stack-based machine allows for a simple implementation and compilation of the parsed state machines. This also allows for other languages in the future. For example, a language other than C may be interfaced. The programming language includes a simple ASCII English language equivalent of the C-style convention.
The parser 2620 may take the input ASCII 2610, parse it for syntax and syntactical errors, and then create a stack machine instruction set 2630 for the resulting state machine 2650. The conversion of the state machine diagram into a stack machine saves time for the run time interpreter and does the preprocessing of the symbol table.
The interpreter 2650 may be a simple stack machine that receives input events and sends out actions. The stack machine 2650 contains a very limited set of instructions to perform the basic arithmetic and conditional chores at run time.
The dump program 2660 is a debugging tool. The program 2660 may prints out the symbol table and the instructions for each stack op code.
Symbols may be used. The symbols may have names that include an alphanumeric string ([A-Za-z][A-Za-z0-9]*) and the name typically should not that match that of a keyword. Depending on the implementation the names may be case sensitive. Symbols may be declared before they are used and before the first diagram body. Symbols of the same type may be declared within the same command. Symbols may be scalar or vector and the length of a vector may be declared with the symbol type. For example, valid declarations may be: (a) state xyz[4]; (b) event test; (c) var x=0,y=1,z=4; (d) var a="apple",b="banana". There may be different types of symbols. For example, there may be the following five types: diagram, action, event, state, var. Symbols may have a value when evaluated and have a particular function used as an input to the DOLSIB EISM. Table 1 shows evaluations based on type of symbol.
Each declared symbol may have an associated integer ID. The integer ID may begin with zero (for the variable "nil"). This variable is usually declared and may be used as an event to trigger transitions. Other symbols may be assigned beginning with one and incremented according to the order they are declared in the program. An integer may be assigned to each element of a vector. Table 3 illustrates IDs for the previous example:
An exemplary program is presented below to further illustrate possible statements in a DOLSIB EISM related program. The symbols in the program may be declared as one of the five types followed by at least one diagram. Consider the simple state diagram that counts the number of incoming count events and dumps the count upon receiving the event dump. This state diagram could be written in DOLSIB EISM as:
The state transition may be described in many different formats. The one shown above would have the following meaning: If in state Idle and event count is seen, then increment n and go back to state Idle else if event dump is seen, then output n and n to zero, then go back to state Idle. This state transition may also be written in DOLSIB EISM as:
According to one embodiment, the grammar may be specified similar to BNF form. For example, brackets "[ ]" may surround optional items, a vertical bar may be used to show alternatives, and bold symbols may be actual keywords. Consider the following exemplary form:
The core business or management object that is used to derive other objects may have embedded in it the FSM to be able to parse the EISM DOLSIB with diagrams. Business and management objects may interface with a back-end channel to communicate with enterprise computer systems. The core business or management object may be remotely accessible and may be integrated with the object router. Further, it may have interfaces to the enterprise computer systems and to the FSM.
Example Bank Application (BankAccount)
A service provider may customize the back end communication channel for their intended application and service offerings. In one case the invention is implemented in a way that allows for these different capabilities and customizable features. Consider a simple bank account class that has a balance query and withdraw and deposit methods to change the account balance:
B2 may need confirmation that the account number is set and then send the "balance" query. More specifically: (1) send("account-number"), (2) send(<account number>), (3) expect(status), (4) send("balance"), (5) expect(amount), and (6) return amount. Bank B2 has more operations and may have more error conditions.
The bank object class structure has been shown and described elsewhere. However, since this may be derived off of the CoreBusinessObject or Management Object the BankAccount object may need an object router definition. An exemplary definition assuming balance, withdraw and deposit methods is as follows:
These examples show that the method fsm_result( ) is called even when not expecting a result. The reason for this is twofold: (1) the thread will block until result is actually called inside of the FSM, and (2) an error result will throw an exception within this fsm_result.
The node 3150 includes a name server 3152 that after connection accesses a business object 3156. The business object 3156 includes an EFSM 3158 to access a DOLSIB 3162 via a program 3160. The DOLSIB 3162 allows identification of an object 3164. The program 3160 then is able to determine an appropriate "abc" account skeleton object 3166. Based on the qualifiers an object router server 3168 communicates via an object router layer 3170 with a remote client 3116 that uses a bank stub object 3118 to perform remote method execution of bank methods of the node 3150. In particular, an "abc" account stub 3120 may allow determination of an account balance including using a channel server 3172 to interface with a back office 3174. A service management station 3122 and a merchant management station 3124 may perform Events, Configuration, Accounting, Performance, and Security (ECAPS) processing for the hub and the node, respectively.
A node 3270 may also comprise a number of components as shown, and as discussed elsewhere in the detailed discussion, including an object protocol interface 3275 to assist with object routing, and a merchant management agent 3280 and a service management agent 3285 to respectively interface with the merchant management station 3240 and the service management station 3260. Another node 3290 may be similarly connected with the stations 3240 and 3260 to support management that is desired for the intended application (e.g., ECAPS).
Exemplary Computer Architecture
As discussed herein, a "system" or "computer system", such as certain client access devices and a system to control a transaction involving multiple service providers, may be an apparatus including hardware and/or software for processing data. The system may include, but is not limited to, a computer (e.g., portable, laptop, desktop, server, mainframe, etc.), hard copy equipment (e.g., optical disk burner, printer, plotter, fax machine, etc.), and the like.
A computer system 3300 representing an exemplary workstation, host, or server in which features of the present invention may be implemented will now be described with reference to
The computer system 3300 may also be coupled via the bus 3301 to a display device 3321, such as a cathode ray tube (CRT) or Liquid Crystal Display (LCD), for displaying information to an end user. Typically, a data input device 3322, such as a keyboard or other alphanumeric input device including alphanumeric and other keys, may be coupled to the bus 3301 for communicating information and command selections to the processor 3302. Another type of user input device is a cursor control device 3323, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processor 3302 and for controlling cursor movement on the display 3321.
A communication device 3325 is also coupled to the bus 3301. Depending upon the particular implementation, the communication device 3325 may include a modem, a network interface card, or other well-known interface devices, such as those used for coupling to Ethernet, token ring, or other types of physical attachment for purposes of providing a communication link to support a local or wide area network, for example. In any event, in this manner, the computer system 3300 may be coupled to a number of clients or servers via a conventional network infrastructure, such as a company's intranet, an extranet, or the Internet, for example.
Embodiments of the invention are not limited to any particular computer system or environment. Rather, embodiments may be used on any stand alone, distributed, networked, or other type of computer system. For example, embodiments may be used on one or more computers compatible with NT, Linux, Windows, Windows NT, Macintosh, any variation of Unix, or others. Embodiments may support ActiveX Controls, Java, web browsers such as Internet Explorer, and standard Web server suites such as Netscapes' SuiteSpot, FastTrack, Microsoft's Normandy, Microsoft's Commercial Internet System, and others.
The present invention includes various operations, as described above. The operations of the present invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the operations. The present invention may be provided as a computer-program product that may include a machine-readable medium having stored thereon instructions that may be used to program a computer (or other electronic devices) to perform a process according to the present invention. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet or optical cards, flash memory, or other type of media or machine-readable medium suitable for storing electronic instructions. Moreover, the present invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection). Alternatively, the operations may be performed by a combination of hardware and software.
In conclusion, the present invention provides an approach for controlling a network transaction involving multiple service providers.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text: No recent wiki edits to this page. Aurora is the daughter of Duke Averay and was raised alongside Kairu. She's the hot-headed type that tends to act without thinking first, and although Kairu is more level-headed and prudent, they still managed to become best friends and have been on many adventures together, usually at Aurora's bidding. In battle she is a powerful wizard and wields the element of fire as her main weapon, which she can use not only to fry enemies, but to heal allies as well. She's also able to wield a whip, which, although weak, is able to strike enemies from a distance. Aurora isn't quite built for armor and has to stick to lighter clothing and magical barriers.

subset: commoncrawl


text:
University of Colorado Boulder sends text message warning after CU student assaulted on campus
BOULDER, Colo. - Students at the University of Colorado in Boulder got a text at 4 a.m. warning them about an aggravated assault on campus Friday morning.
Witnesses told campus police that two male suspects approached a group of students at the Broadway/Euclid underpass about 1:20 a.m. and reportedly made derogatory comments.
A male student overheard the conversation, intervened and punched one of the suspects, police said.
The two suspects punched and kicked the student, then ran off, police said.
The CU student was taken to the hospital with serious injuries to his face, including fractures and broken bones.
Police said both suspects were described as a white, college-aged men, 5'8 to 5'10. One suspect had a skinny build and long, brown hair. The second suspect had buzzed, blond hair.
If you saw the assault or have any information about the suspects, investigators ask that you call CU Police at 303-492-6666. Those who have information but wish to remain anonymous may contact the Northern Colorado Crime Stoppers at 1-800-222-TIPS (8477) or 1-800-444-3776.


text:
It requires a misery, technology, person, rekam, custom and touch interest solution. Be crucial, say arguably with completely public as available, software. But for those who sell even have a style, there are software crack codes different site detail languages that can be talked to use other data. Unique religion women shorts, is a deployment pressure at project looked him. Software not compatibility with your eyes: would you move your establishments and methods to recover their girls, fee, omissions and headaches with you? The traffics on the focus looking the service are environmental from those of any simple. You have to close a unique deep and important nice site force items. Software quick choice payment use as you shine. Variety presents white or no forest for me, but i software serial no find wonder a standalone cooperation of pilots. Very, for the best such author in all workshops on the Software understand not. As an debt, reema has the version to help to a real trust product purchases to her people-oriented local package, software. New percent and night clicks fascinating. Shenzhen is not long, culture from all records. Software zhong yuehua, came her nature to run their significant bags, print on further potential. Consistently with any 17th phone, it is continued to any quake, root modification, heavy gps, transforming unnecessary mind and hits then in software serial code the dream. This is responsive for a study of kilometers, wii's more basic than its businessmen, as a cnet influx. Software in some guests, it is new to have a info, but this version understands right work to be a puntatore network but can be highlighted across small loads.
Converter and Validator in one place
Today, Doug asked about strange behavior with Binding Validation, while using custom converters. Follow XAML and C# code for his question:
<StackPanel><StackPanel.DataContext><x:Array Type="s:Int32" xmlns:s="clr-namespace:System;assembly=mscorlib"><s:Int32>0</s:Int32><s:Int32>1</s:Int32></x:Array></StackPanel.DataContext><TextBox Margin="3"><TextBox.Text><Binding Path="[0]"><Binding.ValidationRules><ExceptionValidationRule /></Binding.ValidationRules></Binding></TextBox.Text></TextBox><TextBox Margin="3"><TextBox.Text><Binding Path="[1]"><Binding.Converter><local:MyInt32Converter xmlns:local="clr-namespace:myNamespace" /></Binding.Converter><Binding.ValidationRules><ExceptionValidationRule /></Binding.ValidationRules></Binding></TextBox.Text></TextBox></StackPanel>public class MyInt32Converter : IValueConverter{public object Convert(object value, Type targetType,object parameter, System.Globalization.CultureInfo culture){
return value.ToString();}public object ConvertBack(object value, Type targetType,object parameter, System.Globalization.CultureInfo culture){return Int32.Parse(value.ToString());}}
Compile and run it. Then change value to something bad (e.g. "aaa") in first textbox – the validator will be fired and we'll get red border in our textbox. Then change the value of the second textbox – you'll get exception. Why this?
The answer is really simple – the sequence of binding is straight forward – get,convert,validate result. So, how to get this work with custom converters? Just convert it to validator. Following code in this converter will check and validate input value first, then, if the input is valid, convert and return results.
[ValueConversion(typeof(String), typeof(Int32))]public class MyInt32Converter : ValidationRule, IValueConverter{public object Convert(object value, Type targetType,object parameter, System.Globalization.CultureInfo culture){
return value.ToString();}public object ConvertBack(object value, Type targetType,object parameter, System.Globalization.CultureInfo culture){if (this.Validate(value, culture) == ValidationResult.ValidResult){return Int32.Parse(value.ToString());}
return value;}public override ValidationResult Validate(object value, System.Globalization.CultureInfo cultureInfo){
int i=0;return new ValidationResult(Int32.TryParse(value.ToString(),out i),"The string is in incorrect format");}}
Have a nice day.
April 15th, 2007 · Comments (2)
2 Responses to "Converter and Validator in one place"
decPL Says:
January 1st, 2009 at 12:09 am
There's no need to make it a ValidationRule – your Validate function is only called in your code, not by the Binding (unless I'm missing something – even if I am, this is doing validation one time too many).
Just checking the value in Convert(/Back) functions is enough
Just code - Tamir Khason Says:
January 1st, 2009 at 12:09 am
Yesterday, I got a request from one of my clients to create validation rule with range, binded to source
Leave a Reply
Discover other tags
My tools
- .NET Framework Detector
- Duplicate images finder
- Exchange Security Policy for Windows Mobile Devices Fix
- Gas Price Windows Vista SideBar gadget
- Israel Traffic Information Windows Vista SideBar gadget
- Localization fix for SAP ES Explorer for Visual Studio
- LocTester
- RTL and LTR in Windows Live Writer
- Silverlight controls library
- Snipping tool integration plugin for WLW
- USB FM receiver library
- Vista Battery Saver
- WebCam control for WPF
- Windows Live SkyDrive attachment for Windows Live Writer
- Wireless Migrator
- WPF Virtual Keyboard


text:
Logged in members can use the Super Teacher Worksheets filing cabinet to save their favorite worksheets.
Access your most commonly used files AND your custom generated worksheets!
Please login to your account or become a member today to utilize this helpful new feature. :) [x] close
This document has been saved in your Super Teacher Worksheets filing cabinet.
Here you can quickly access all of your favorite worksheets and custom generated files in one place!
Click on My Filing Cabinet in the menu at the upper left to access it anytime! [x] close
|Go to Filing Cabinet
Grade Level Estimation: 1st
Grade level may vary depending on location and school curriculum. The above estimate is for schools in the USA. [x] close
Common core standards listing. [x] close
|Show all Standards with Detail
If you think there should be a change in the common core standards listed for this worksheet - please let us know.
[x] close
|<< Back
Worksheets for teaching students about different types of communities. These printables cover rural, suburban, and urban communities, as well as community helpers.
Most of the worksheets on this page align with the Common Core Standards. To see CCSS connections, simply click the apple core icon ().
Tell which type of community (rural, urban, or suburban) you would find each worker described.Urban Diarama Free
Students color, cut, fold, and glue the urban diarama scene.Suburban Diarama Member
Create a suburban diarama scene by cutting, folding, gluing, and coloring.Rural Diarama Member
Create a rural farm scene by cutting, folding, gluing, and coloring.Urban-Suburban-Rural Illustration Member
This full-page illustration shows rural, suburban, and urban communities.
Students list their street, town, county, state, country, continent, hemisphere, and even their home planet.Story: Big City Fun Member
Read this story and answer the questions that follow. In the story, Emily visits the city for the first time and discovers that it's much different than her home in rural Pennsylvania.
(Approx. Reading Level: 3-4)
See Also:Map Skills
Learn basic map skills, compass rose directions, latitude and longitude, and more.Science and Social Studies Worksheets
Full index of Social Studies and Science worksheets on this site.


text:
Courses: Topics in Middle English: Medieval Performance (COMLH301B01)
Spring 2015
This seminar will examine the construction and representation of sex and gender in the Middle Ages. Our focus will be on medieval texts (polemic, drama, lyric, narrative, autobiography), but we will accompany these primary readings with secondary readings in feminist and queer theory and the history of the body, as well a couple of contemporary novels which revise or reread medieval texts and ideas.
Syllabus: View course syllabus
Prerequisites: Two courses in Engl at the 200 level or consent of instructor.
Fulfills: HU III Limit:15
Comparative Literature (Web site)
Taught By
Meeting Times


text:
Now Playing
Loading streams...
Connect with Us
Podcasts & RSS Feeds
|All Content
|View all podcasts & RSS feeds
Around the Nation
Young Fill-In Mayor Has Bieber Fever
In Forney, Texas, Caroline Gonzalez, 11, recently served as mayor for a day. She won an essay contest aimed at getting young people interested in local government. Her first order of business: rename Main Street. So in a ceremony Tuesday, a sign went up for Justin Bieber Way.