WO2002093289A2 - Services utilisant le web mobile - Google Patents

Services utilisant le web mobile Download PDF

Info

Publication number
WO2002093289A2
WO2002093289A2 PCT/IB2002/001585 IB0201585W WO02093289A2 WO 2002093289 A2 WO2002093289 A2 WO 2002093289A2 IB 0201585 W IB0201585 W IB 0201585W WO 02093289 A2 WO02093289 A2 WO 02093289A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
search
wireless device
uddi
registry
Prior art date
Application number
PCT/IB2002/001585
Other languages
English (en)
Other versions
WO2002093289A3 (fr
Inventor
Petri Nykänen
Original Assignee
Nokia Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/854,619 external-priority patent/US7155425B2/en
Application filed by Nokia Corporation filed Critical Nokia Corporation
Priority to AU2002302871A priority Critical patent/AU2002302871A1/en
Priority to EP02730556A priority patent/EP1388032A4/fr
Publication of WO2002093289A2 publication Critical patent/WO2002093289A2/fr
Publication of WO2002093289A3 publication Critical patent/WO2002093289A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the invention disclosed broadly relates to methods for providing Internet services and more particularly relates to improvements in mobile device accessing of Internet and other network services.
  • UDDI Universal Description, Discovery and Integration
  • the UDDI registry enables users to discover services and businesses on the Internet.
  • the UDDI standard takes advantage of World Wide Web Consortium (W3C) standards and Internet Engineering Task Force (IETF) standards such as Extensible Markup Language (XML), Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) protocol, and Simple Object Access Protocol (SOAP) messaging protocol.
  • W3C World Wide Web Consortium
  • IETF Internet Engineering Task Force
  • XML Extensible Markup Language
  • HTTP Hypertext Transfer Protocol
  • DNS Domain Name System
  • SOAP Simple Object Access Protocol
  • the UDDI registry enables users to quickly, easily and dynamically find businesses and services on the Internet.
  • the UDDI registry enables businesses to reach their customers and partners with information about their products and Web services.
  • the UDDI registry also enables businesses to integrate into each other's systems and processes. Registering enables a business to publicly list basic information about its company and offerings.
  • the Nokia WAP Client Version 2.0 is a software product containing the components necessary to implement a WAP client on a wireless device. These components include a Wireless Markup Language (WML) Browser, WMLScript engine, Push Subsystem, and Wireless Protocol Stack.
  • WML Wireless Markup Language
  • the Nokia WAP Client is a source-code product that can port and integrate into wireless devices such as mobile phones and wireless PDAs. Application programs stored in the wireless device interact with the WAP Client to implement a variety of communications applications. Details of the Nokia WAP Client Version 2.0 can be found in the online paper: Nokia WAP Client Version 2.0. Product Overview. Nokia Internet Communications, 2000, www.nokia.
  • Digital communications networks can be categorized in terms of their geographic coverage, their transmission media, their protocols, their transmission speeds, the types of equipment that they interconnect, and other criteria.
  • geographic coverage categories includes wide area networks (WANs), metropolitan area networks (MANs), local area networks (LANs), and personal area networks (PANs).
  • An example of transmission media categories includes fixed station wireline networks, mobile wireless networks, and hybrid combinations of fixed station wireline networks communicating through wireless access points with wireless networks.
  • WANs wide area networks
  • MANs metropolitan area networks
  • LANs local area networks
  • PANs personal area networks
  • An example of transmission media categories includes fixed station wireline networks, mobile wireless networks, and hybrid combinations of fixed station wireline networks communicating through wireless access points with wireless networks.
  • PSTN public switched telephone network
  • GSM Global System for Mobile Communication
  • DAMPS Digital Advanced Mobile Phone Service
  • PDC Personal Digital Cellular
  • GPRS General Packet Radio Service
  • W- CDMA Wideband GPRS
  • Wide area networks can include communications satellite links that interconnect nation-wide digital networks located on different continents.
  • National-wide digital networks typically include backbone networks, regional distribution hubs, and routers, which interconnect access subnetworks serving local routers, servers, and service providers.
  • the Internet is a familiar example of a wide area network. For more information on the Internet as a wide area network, see the book by Daniel Minoli, et al. entitled Internet Architectures. John Wiley & Sons, 1999.
  • Short-range wireless systems have a typical range of one hundred meters or less. They often combine with systems wired to the Internet to provide communication over long distances.
  • the category of short-range wireless systems include both a wireless personal area network ("PAN”) and a wireless local area network (“LAN”). Both of these networks have the common feature of operating in unlicensed portions of the radio spectrum, usually either in the 2.4 GHz Industrial, Scientific, and Medical (ISM) band or the 5 GHz Unlicensed- National Information Infrastructure (“U-NII”) band.
  • ISM Industrial, Scientific, and Medical
  • U-NII Unlicensed- National Information Infrastructure
  • Wireless personal area networks use low cost, low power wireless devices that have a typical range often meters.
  • the best- known example of wireless personal area network technology is the Bluetooth Standard, which operates in the 2.4 GHz ISM band.
  • Wireless local area networks generally operate at higher peak speeds of from 10 to 100 Mbps and have a longer range, which requires greater power consumption.
  • Wireless local area networks are typically used as wireless links from portable laptop computers to a wired LAN, via an access point (AP). Examples of wireless local area network technology include the IEEE 802.11 Wireless LAN Standard and the HIPERLAN Standard, which operates in the 5 GHz U-NII band. For more information on wireless LANs, see the book by Jim Geier entitled Wireless LANs. Macmillan Technical Publishing, 1999.
  • An ad hoc network is a short range wireless system composed primarily of mobile wireless devices, which associate together for a relatively short time to carry out a common purpose.
  • a temporary network such as this is called a "piconet” in the Bluetooth Standard, an "independent basic service set” ("IBSS") in the IEEE 802.11 Wireless LAN Standard, a “subnet” in the HIPERLAN Standard, and generally a radio cell or a "micro-cell” in other wireless LAN technologies.
  • Ad hoc networks have the common property of being an arbitrary collection of wireless devices, which are physically close enough to be able to communicate and which are exchanging information on a regular basis. The networks can be constructed quickly and without much planning.
  • Ad hoc networks consist primarily of mobile wireless devices, but can also include one or more access points, which are stationary wireless devices operating as a stand-alone server or connected as gateways to other networks.
  • What is needed is the ability of a mobile phone or wireless PDA to discover Internet businesses and services by accessing the UDDI registry. It would be even more useful to facilitate the formation of a query to the UDDI registry for the wireless device user. It would be beneficial to maintain a personal profile of the user's Internet accessing preferences and to use that profile in formulating a detailed UDDI query of the UDDI registry from the user's abbreviated inputs to the wireless device. What is also needed is a generic facility to invoke required components in a user terminal and in a server to execute services for the end user. Incorporation of pre- and post-processing applications, along with search agents, would greatly increase the flexibility of mobile web services. Terminals with limited memory capacity would further require interaction protocols that would accommodate such devices.
  • a system and method to enable a mobile phone or wireless PDA to discover Internet businesses and services by accessing the Universal Description, Discovery and Integration (UDDI) registry.
  • the method facilitates the formation of a query to the UDDI registry for the wireless device user.
  • the method constructs a personal user profile of the user's UDDI searching strategies and Internet accessing preferences.
  • the user profile can be used as a shortcut for online or offline queries to the UDDI registry or for accessing pages from web sites, in response to the user's entry of abbreviated inputs to the wireless device.
  • the method is embodied as programmed instructions which may be executed within the user's wireless device to query the UDDI registry.
  • method is embodied as programmed instructions which may be executed within a separate knowledge engine server to query the UDDI registry in response to commands from the user's wireless device.
  • the server can be used to cache files accessed from web sites, for selective forwarding to the user's wireless device. Additional programmed instructions are acquired by the device and executed within the device to communicate with mobile web services that are made available through business-end servers.
  • a terminal configured with advanced search functionality contacts a service provider that has stored history information of a users.
  • a knowledge engine of the service provider performs pre-processing of queries sent by a terminal, or may provide back the pre-processed query to the terminal for enabling a direct request from the terminal to a preferred search engine or system.
  • Post-processing capabilities for searches received from the knowledge engine may also be included in the terminal.
  • the knowledge engine may further act as a search agent for the user and make queries on behalf of the terminal.
  • search results When search results are received back to the knowledge engine or terminal, the search results may be filtered or prioritized and sorted based on user profile information available to the knowledge engine. Additional components may be added to the search to enable branding of the search functionality.
  • an invocation server may be implemented in a web services site to facilitate mobile web applications.
  • Service logic can be set up in the server to serve as an intermediary between mobile web services and a server.
  • Mobile web services are set up to be customized for each web services site, and can be securely downloaded by terminals by invoking the service get_access to the service logic in the site.
  • the mobile web services may be partitioned and invoked separately as needed.
  • the sequence of operational steps for the wireless device's UDDI registry browsing method begins by entering a search handle that will be associated with the user's search strategy. Then the query terms are entered by the user, which may be a business name, part of a business name, a service description, or other characterization. If the characterization is part of a business name, the wireless device then sends Rand business XML inquiry using Simple Object Access Protocol (SOAP) to the UDDI registry. The wireless device then receives back from the UDDI registry, a businessList message that contains a list of business names satisfying the find_business query. The user can then select an item from the returned businessList message and drill-down in the selected business' entity data.
  • SOAP Simple Object Access Protocol
  • the wireless device then sends a find service XML inquiry using SOAP to the UDDI registry.
  • the wireless device then receives back from the UDDI registry, a serviceList message that contains a list of names of services offered by the selected business. The user can then select an item from the returned serviceList message and drill-down in the selected service data.
  • the wireless device then sends a _get_serviceDetail_ XML inquiry using SOAP to the UDDI registry.
  • the wireless device then receives back from the UDDI registry, a serviceDetail message that includes bindingTemplate data that contains the details of the selected service. Included in the bindingTemplate data is the accessPoint URL, which is the URL of the selected service on the web site of the selected business.
  • the service details may be comprehensive or abbreviated, and may also be prioritized according to the needs of the user (or not prioritized at all).
  • the wireless device then displays the accessPoint URL to the user.
  • the wireless device also stores the search handle in user profile with the selected accessPoint URL, to enable the user to access web pages from the web site of the selected business. This provides the user with a shortcut for accessing pages from web sites, in response to the user's entry of abbreviated search handle to the wireless device.
  • the wireless device also stores the search handle in user profile with the UDDI registry search strategy.
  • the stored search strategy includes the business name query , the selected businessEntity data, the selected business Service data, the selected bindingTemplate data, and the selected accessPoint URL.
  • This provides the user with a shortcut for online or offline queries to the UDDI registry, in response to the user's entry of abbreviated search handle to the wireless device.
  • the search handle may be associated with an icon on the user's screen. Thus, activation of the icon by the user would initiate the shortcut.
  • the user merely enters a search handle into the wireless device and selects the replay option.
  • the wireless device then accesses the UDDI registry search strategy from user profile corresponding to the search handle and loads the business name query , the selected businessEntity data, the selected businessService data, and the selected bindingTemplate data as each respective operand that would have been otherwise entered by the user. If the data in the UDDI registry has been updated since the user's last query, the bindingTemplate data may contain additional or modified accessPoint URLs, of the selected service on the web site of the selected business.
  • the sequence of operational steps described above for the wireless device's UDDI registry browsing method can also be carried out in a separate knowledge engine server.
  • the server performs the above described method to query the UDDI registry in response to commands from the user's wireless device.
  • the knowledge engine in the server begins by receiving user's query or search handle. If a search handle has been received, then the server replays a corresponding search strategy for the UDDI registry accessed from the user's profile and uses the query steps specified in the strategy instead of requesting further inputs from the user.
  • the server accesses the UDDI registry using the method described above to identify web sites.
  • the server returns a list of web sites to the user and stores binding templates in the user's profile.
  • the server receives the user's selection of web sites to search and the server updates user profile with these preferences.
  • the server begins by receiving the user's new query or the user's search handle, the server proceeds to search the identified web sites using the URLs contained in the stored binding templates.
  • the server retrieves any documents resulting from the search of the specified web sites.
  • the server applies a filter that is prescribed by the user and stored in the user's profile, to limit the returned documents to only those of particular interest to the user.
  • the server sorts the documents in a list having an order established in accordance with user's profile.
  • the server further stores the filtered documents and the sorted list in a cache for later use.
  • the documents may subsequently be accessed selectively by the user.
  • the server also returns the list of documents to user, and if the user is not logged on, the list will be returned to the user when he/she next logs on.
  • the filter may be automatically created, based on the profile information or history information available on the interests of the user.
  • a server determine interests of a user through earlier selections that were made.
  • the server receives the user's selections from the list and it updates the user's profile with the user's preferences.
  • the server then returns the selected documents to user.
  • the knowledge engine server associates the search handle with user's selections and with the user's search strategy, storing that association in user's profile.
  • the term "document" under the present invention relates not just to web page documents, but also to services such as streaming video, audio or other application-specific communication.
  • the present disclosure is not limited to just browsing after user discovery has taken place.
  • Figure 1 is a network diagram of the invention, showing an exemplary relationship between the user's Wireless Application Protocol (WAP)-enabled portable wireless device, the WAP protocol gateway to the Internet, the knowledge engine server, the Universal Description, Discovery and Integration (UDDI) registry, and a plurality of web sites;
  • WAP Wireless Application Protocol
  • UDDI Universal Description, Discovery and Integration
  • Figure 1A through 1H show the user's wireless device in a progression of stages as it carries out the UDDI registry browsing method
  • Figure II and 1J show the user's wireless device in a progression of stages as it carries out the method of replaying a UDDI registry search strategy as a shortcut for online or offline queries to the UDDI registry;
  • Figure 2 is a functional block diagram of the wireless device 100, showing its various components and programs;
  • Figure 2 A is a flow diagram of the sequence of operational steps for the wireless device's UDDI registry browsing program;
  • Figure 2B is a flow diagram of the sequence of operational steps for the wireless device's program to replay the UDDI registry search strategy
  • Figure 3 A is a network process flow diagram of the interaction of the wireless device and the UDDI registry when carrying out the UDDI registry browsing program of Figure 2A;
  • Figure 3B is a network process flow diagram of the interaction of the wireless device and the UDDI registry when carrying out the program to replay the UDDI registry search strategy;
  • Figure 4 is a functional block diagram of the knowledge engine server, showing the memory storing the application services software programs needed to perform the operations of the invention
  • Figure 4A is a more detailed functional block diagram of the server, showing the knowledge engine
  • Figure 4B is a network process flow diagram of the interaction of the wireless device, the knowledge engine server, and the UDDI registry when carrying out the UDDI registry browsing program in the server;
  • Figure 5 illustrates an embodiment of web services wherein a user's wireless device communicates to a mobile network which in turn is communicatively coupled to an Internet/internet network;
  • Figure 6A illustrates an example of advanced search and result processing
  • Figure 6B illustrates another example of advanced search and result processing
  • Figure 6C illustrates advanced search and result processing, wherein a terminal is not utilizing a UDDI system
  • Figure 6D illustrates a process of invocation mobile web services
  • Figure 7 illustrates yet another embodiment, wherein a terminal communicates through a mobile network to web service sites to access mobile web services
  • Figure 8 A illustrates layered interaction of web services utilizing a description/discovery services layer and a web services layer
  • Figure 8B illustrates another layered interaction of web services utilizing a description discovery services layer, a web services layer, and a mobile web services layer.
  • the invention is applied to wireless telephones and wireless personal digital assistants
  • FIG. 1 is a network diagram of an embodiment of the invention, illustrating a relationship between the user's Wireless Application Protocol (WAP)-enabled portable wireless device 100, a WAP protocol gateway 120, and the server 140.
  • the user's WAP-enabled portable wireless device 100 can be a wireless mobile phone, pager, two-way radio, smartphone, personal communicator, or the like.
  • the user's WAP-enabled portable wireless device 100 accesses a small file called a deck which is composed of several smaller pages called cards which are small enough to fit into the display area of the device's microbrowser 102.
  • the small size of the microbrowser 102 and the small file sizes accommodate the low memory constraints of the portable wireless device 100 and the low-bandwidth constraints of a wireless network 116.
  • the cards are written in the Wireless Markup Language (WML) which is specifically devised for small screens and one-hand navigation without a keyboard.
  • WML Wireless Markup Language
  • the WML language is scaleable from two-line text displays on the microbrowser 102 of a cellular telephone, up through large LCD screens found on smart phones and personal communicators.
  • the cards written in the WML language can include programs written in WMLScript, which is similar to JavaScript, but makes minimal demands on memory and CPU power of the device 100 because it does not contain many of the unnecessary functions found in other scripting languages.
  • the Nokia WAP Client Version 2.0 is a software product containing the components necessary to implement a WAP client on a wireless device. These components include a Wireless Markup Language (WML) Browser, WMLScript engine, Push Subsystem, and Wireless Protocol Stack.
  • the Nokia WAP Client is a source-code product that can port and integrate into wireless devices such as mobile phones and wireless PDAs. Application programs stored in the wireless device interact with the WAP Client to implement a variety of communications applications. Details of the Nokia WAP Client Version 2.0 can be found in the online paper: Nokia WAP Client Version 2.0. Product Overview. Nokia Internet Communications, 2000, www.nokia.com/corporate/wap.
  • the system and methods disclosed herein are applicable to other platforms as well, such as XHTML, and is not limited strictly to the WAP protocol.
  • the user's WAP-enabled portable wireless device 100 communicates with the radio tower 114 and can exchange messages for distances up to several kilometers.
  • the types of wireless networks 116 supported by the WAP standard include Cellular Digital Packet Data (CDPD), Code-Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), GPRS, 3G-Broadband, and the like.
  • the overall process of communication between the user's WAP-enabled wireless device (the client) 100, through the WAP protocol gateway 120, to the server 140 resembles the way Web pages are served on the Internet using the HyperText Transfer Protocol (HTTP) or World Wide Web protocol: [1]
  • HTTP HyperText Transfer Protocol
  • the user's device 100 sends the URL, via the radio tower 114 and the wireless network 116, to the gateway 120 using WAP protocols.
  • the gateway 120 translates the WAP request into an HTTP request and sends it over the Internet 130 to the server 140, via Transmission Control Protocol/ Internet Protocol (TCP/IP) interfaces.
  • TCP/IP Transmission Control Protocol/ Internet Protocol
  • the server 140 handles the request just like any other HTTP request received over the internet.
  • the server 140 either returns a WML deck or a HyperText Markup Language (HTML) page back to the gateway 120 using standard server programs written, for example in Common Gateway Interface (CGI) programs, Java servlets, or the like.
  • CGI Common Gateway Interface
  • the gateway 120 receives the response from the server 140 on behalf of the user's device 100. If the response is an HTML page, it gets transcoded into WML if necessary. Then the WML and WMLScript coding is encoded into a byte code that is then sent to the user's device 100. [6] The user's device 100 receives the response in the WML byte code and displays the first card in the deck on the microbrowser 102 to the user.
  • the protocol gateway 120 includes a WAP protocol stack organized into five different layers (not shown).
  • An application layer is the wireless application environment, which executes portable applications and services.
  • a session layer is the wireless session protocol, which supplies methods for the organized exchange of content between client/server applications.
  • a transaction layer is the wireless transaction protocol, which provides methods for performing reliable transactions.
  • a security layer is the wireless transport layer security, which provides authentication, privacy, and secure connections between applications.
  • the transport layer is the wireless datagram protocol, which shelters the upper layers from the unique requirements of the diverse wireless network protocols, such as CDPD, CDMA, GSM, etc. Additional information about the WAP standard and the WAP protocol stack can be found in the book by Charles Arehart, et al.
  • the user's portable wireless device 100 includes the microbrowser 102 displaying the Mobile Web Services menu, that enables the user to navigate through the cards being displayed and to select options that are programmed by the application programs 106.
  • the user's device 100 also includes the WAP client program 108 which has been previously discussed.
  • the Mobile Web Services menu displayed by the microbrowser 102 in Figure 1 is rendered by the WAP client program 108 under the control of the application programs 106, which are further illustrated in Figures 2, 2A, and 2B.
  • the user can select the session type utilizing the Mobile Web Services menu, by either [A] a direct session with the UDDI registry or [B] an indirect session with the UDDI registry through a knowledge server 140.
  • the direct session with the UDDI registry is further illustrated in the network process flow diagrams of Figures 3 A and 3B.
  • the knowledge service adds value to UDDI searches with pre and post-processing, regardless of the device being used to access UDDI.
  • the indirect session with the UDDI registry through the knowledge server 140 is further illustrated in the network process flow diagram of Figure 4B. Whichever session type is selected by the user, the Mobile Web Services menu of Figure 1 presents to the user the UDDI Registry Search Menu from which the user can select the following options:
  • Option [1] of browsing the UDDI registry for web site URLs allows the user to explore and examine data organized by the UDDI registry in a hierarchy.
  • the core information model used by the UDDI registries is defined in an XML schema. XML allows hierarchical relationships to be described for four types data: business information; service information, binding information; and information about specifications for services.
  • a first type of data is Business information, which is specified in the UDDI registry with the businessEntity XML element.
  • the businessEntity XML element typically includes the name, general description, contacts, and categories of the business whose web site is on the Web.
  • the businessEntity XML element serves as the top of the information hierarchy for all of the information about a business under the present embodiment.
  • a second type of data is Service information, which is specified in the UDDI registry with the businessService XML element.
  • One or more businessService XML elements is contained in each businessEntity XML element.
  • the businessService XML element includes one or more bindingTemplate XML elements, which are a third type of data.
  • the businessService XML element is a descriptive container that is used to group a series of related Web services related to either a business process or category of services, such as purchasing services, shipping services, news services, and other high-level business processes.
  • the businessService XML element information sets can each be further categorized in combinations of industry, product and service or geographic subjects.
  • the bindingTemplate XML element contains the detailed technical descriptions of Web services. As such, these structures provide the technical entry point URL for specific services and products offered by a business.
  • Each bindingTemplate XML element structure has a single logical businessService XML element parent, which in turn has a single logical businessEntity XML element parent.
  • An important piece of information in the bindingTemplate XML element is the accessPoint element.
  • the accessPoint element is the URL of a specific service provided by the business.
  • a single attribute is typically provided, and is identified in the present embodiment as URLType.
  • the purpose of the URLType attribute is to facilitate searching for entry points associated with a particular type of service.
  • An example might be a purchase order service that provides three entry points, one for HTTP, one for SMTP, and one for FAX ordering.
  • a businessService XML element contains three bindingTemplate XML element entries, each with identical data with the exception of the accessPoint value and URLType value.
  • a fourth type of data in the UDDI registry is the tModel XML element, which is pointed to by a pointer in the bindingTemplate XML element.
  • the tModel XML element specifies the protocols, interchange formats and interchange sequencing rules for accessing web pages from the business' server having the service information specified in the businessService XML element.
  • Option [1] of browsing the UDDI registry for web site URLs involves starting with some broad information, performing a search, finding general result sets and then selecting more specific information for drill-down.
  • the UDDI registry accommodates the browse pattern with the find xx API call. These calls form the search capabilities provided by the UDDI registry and are matched with return messages that return overview information to match the supplied search criteria.
  • a typical browse sequence may involve finding whether a particular business has any information registered in the UDDI registry. This sequence would start with a call find_business, and may subsequently pass the first few characters of the businesses name. The UDDI registry would then return a businessList result.
  • the businessList result is a list of overview information (keys, names and description) of the businessEntity information that matched the search results returned by the find_business query.
  • Figure 1A through 1H illustrate the user's wireless device in a progression of stages as it carries out the UDDI registry browsing method.
  • Figure 2 A illustrates a flow diagram of the sequence of operational steps for the wireless device's UDDI registry browsing program.
  • Figure 3 A illustrates a network process flow diagram, showing the interaction of the wireless device and the UDDI registry when carrying out the UDDI registry browsing program of Figure 2 A.
  • the user can drill-down into their businessService information.
  • the user may search for particular service types (e.g. purchasing, shipping, news and the like) using the find_service API call.
  • the user knows the technical fingerprint (tModel signature) of a particular product and wants to see if the business he/she has chosen supports a compatible service interface, the user can use the find-binding API call.
  • the user has a key for one of the four main data types managed by the UDDI registry, he/she can use that key to access the full registered details for a specific data type (businessEntity, businessService, bindingTemplate, or tModel).
  • the full registered information for any of these structures can be accessed by passing a relevant key type to one of the get _xx API calls to the UDDI registry.
  • one of the data items returned by all of the find-xx return sets is key information.
  • the businessKey value returned within the contents of a businessList structure can be passed as an argument to the UDDI registry to get businessDetail.
  • the successful return of this message is a businessDetail message containing the full registered information for the entity whose key value was passed.
  • This typically will be a full businessEntity structure. Since full businessEntity structures can contain a large quantity of information, it can be optionally cached in the cache 144 of the knowledge engine server 140 of Figure 1.
  • the user can access the accessPoint element of the bindingTemplate XML element in the businessEntity structure to obtain the URL of a specific service provided by the business.
  • Option [3] invokes the business' web site 160 with the cached URL to access the desired web pages. Since the accessed web pages from the web site 160 can contain a large quantity of information, it can be optionally cached in the cache 144 of the knowledge engine server 140 of Figure 1.
  • the terminal may use the bindingTemplate 's unique ID to fetch a new bindingTemplate instance from the UDDI registry, assuming that the new instance contains up-to-date information on the service.
  • Option [4] enables the user to replay a prior UDDI registry search strategy.
  • the user typically enters a previously used search handle into the wireless device and selects the replay Option [4].
  • the wireless device then accesses the UDDI registry search strategy from the user's stored profile corresponding to the search handle and loads the business name query, the selected businessEntity data, the selected businessService data, and the selected bindingTemplate data as each respective operand that would have been otherwise entered by the user. If the data in the UDDI registry has been updated since the user's last query, the bindingTemplate data may contain additional or modified accessPoint URLs, of the selected service on the web site of the selected business.
  • Figure II and 1J illustrate the user's wireless device in a progression of stages as it carries out the method of replaying a UDDI registry search strategy as a shortcut for online or offline queries to the UDDI registry.
  • Figure 2B discloses a flow diagram of the sequence of operational steps for the wireless device's program to replay the UDDI registry search strategy.
  • Figure 3B is a network process flow diagram of the interaction of the wireless device and the UDDI registry when carrying out the program to replay the UDDI registry search strategy.
  • the Mobile Web Services menu of Figure 1 A begins by entering a search handle that will be associated with the user's search strategy.
  • the query terms are subsequently entered by the user, which may be a business name, part of a business name, a service description, or other characterization. If the characterization is part of a business name, the wireless device then sends Rand business XML inquiry using Simple Object Access Protocol (SOAP) to the UDDI registry.
  • SOAP Simple Object Access Protocol
  • the wireless device receives back from the UDDI registry, a businessList message shown in the Mobile Web Services menu of Figure IB, that contains a list of business names satisfying the find business query.
  • the user can then select an item from the returned businessList message and drill-down in the selected business' entity data.
  • the Mobile Web Services menu of Figure 1C shows the wireless device then sending Rand_service XML inquiry using SOAP to the UDDI registry.
  • the Mobile Web Services menu of Figure ID shows the wireless device then receiving back from the UDDI registry, a serviceList message that contains a list of names of services offered by the selected business.
  • the user can then select an item from the returned serviceList message and drill- down in the selected service data, as shown by the Mobile Web Services menu of Figure IE.
  • the wireless device then sends a _get_serviceDetail_ XML inquiry using SOAP to the UDDI registry, as shown by the Mobile Web Services menu of Figure IE.
  • the Mobile Web Services menu of Figure IF then shows the wireless device receiving back from the UDDI registry a serviceDetail message that includes bindingTemplate data that contains the details of the selected service. Included in the bindingTemplate data is the accessPoint URL, which is the URL of the selected service on the web site of the selected business.
  • the Mobile Web Services menu of Figure 1G shows the wireless device displaying the accessPoint URL to the user.
  • the Mobile Web Services menu of Figure 1H shows that the serviceDetail message can contain one or a plurality of URLs, depending on the number of matches made against the user's query in the search by the UDDI registry.
  • the wireless device also stores the search handle in user profile with the selected accessPoint URL, to enable the user to access web pages from the web site of the selected business. This provides the user with a shortcut for accessing pages from web sites, in response to the user's entry of abbreviated search handle to the wireless device.
  • the wireless device also stores the search handle in user profile with the UDDI registry search strategy.
  • the stored search strategy includes the business name query , the selected businessEntity data, the selected businessService data, the selected bindingTemplate data, and the selected accessPoint URL. This provides the user with a shortcut for online or offline queries to the UDDI registry, in response to the user's entry of abbreviated search handle to the wireless device.
  • the user enters a search handle into the wireless device and selects the replay option, as shown in the Mobile Web Services menu of Figure II.
  • the wireless device then accesses the UDDI registry search strategy from user profile corresponding to the search handle and loads the business name query , the selected businessEntity data, the selected businessService data, and the selected bindingTemplate data as each respective operand that would have been otherwise entered by the user. If the data in the UDDI registry has been updated since the user's last query, the bindingTemplate data may contain additional or modified accessPoint URLs, of the selected service on the web site of the selected business, as shown by the Mobile Web Services menu of Figure 1J.
  • Figure 2 is a functional block diagram of the wireless device 100, and illustrates its various components and programs.
  • Figure 2 discloses the memory 202 connected by means of the bus 204 to the radio 206, the keypad 104, the central processor 210 and the display 212.
  • the memory 202 contains program modules each consisting of a sequence of programmable instructions.
  • the wireless devices UDDI registry browsing program 240 (see Figure 2 A) is stored in the memory 202.
  • the wireless devices replay UDDI registry search strategy program 270 (see Figure 2B) is also stored in the memory 202.
  • the indirect session thru server program 220 is also stored in the memory 202.
  • User data 222 is stored in the memory 202, which includes the user ID 230 and the user profile 232.
  • the user profile 232 includes the user's name and email address, the user's search handles, the UDDI search strategies, the sorting and filtering specifications, selected URLS, selected document titles and binding templates which contain URLS.
  • the cache 224 wherein documents and lists returned from a website, can be stored.
  • the WAP client program 108 is stored in the memory 202.
  • Figure 2a is a flow diagram disclosing the sequence of operational steps for the wireless device's UDDI registry browsing program 240. The steps depicted in Figure 2A are as follows:
  • Step 250 WIRELESS DEVICE BROWSING UDDI REGISTRY ENTER SEARCH
  • Step 252 ENTER QUERY TERMS "_WALL STREET_" + “_FINANC*_” IS
  • Step 254 SEND "_find_business_” XML INQUIRY WITH SOAP PROTOCOL TO UDDI REGISTRY
  • Step 256 SELECT ITEM FROM RETURNED businessList MESSAGE DRILL-
  • Step 258 SEND "_find_service_” XML INQUIRY WITH SOAP PROTOCOL TO UDDI REGISTRY Step 260: SELECT ITEM FROM RETURNED serviceList MESSAGE DRILL- DOWN BUSINESS SERVICE DATA "_TECH STOCK NEWS_” Step 262 : SEND _get_serviceDetail_ XML INQUIRY WITH SOAP PROTOCOL
  • Step 268 STORE SEARCH HANDLE "_STOCKS_” IN USER PROFILE WITH UDDI REGISTRY SEARCH STRATEGY: BUSINESS NAME QUERY "_WALL STREET_” + “_FINANC*_” businessEntity DATA SELECTED “_WALL STREET JOURNAL ONLINE_” businessService DATA SELECTED “_TECH STOCK NEWS_” bindingTemplate DATA
  • Figure 2B shows a flow diagram of the sequence of operational steps for the wireless device's program to replay the UDDI registry search strategy.
  • Figure 2B includes the following steps:
  • Step 271 REPLAY UDDI REGISTRY SEARCH STRATEGY ENTER SEARCH HANDLE "_STOCKS_”.
  • Step 272 ACCESS UDDI REGISTRY SEARCH STRATEGY IN USER PROFILE
  • Step 274 SEND Jind_business_ SML INQUIRY WITH SOAP PROTOCOL TO UDDI REGISTRY.
  • Step 276 SELECT ITEM FROM RETURNED businessList MESSAGE DRILL- DOWN BUSINESS ENTITY DATA "_WALL STREET JOURNAL ONLINE ".
  • Step 278 SEND Jind_service_ XML INQUIRY WITH SOAP PROTOCOL TO UDDI REGISTRY.
  • Step 280 SELECT ITEM FROM RETURNED serviceList MESSAGE DRILL- DOWN BUSINESS SERVICE DATA "_TECH STOCK NEWS_”.
  • Step 282 SEND _get_serviceDetail_ XML INQUIRY WITH SOAP PROTOCOL TO UDDI REGISTRY.
  • Figure 3 A discloses a network process flow diagram showing the interaction of the wireless device and the UDDI registry when carrying out the UDDI registry browsing program of Figure 2 A.
  • the network process flow diagram in Figure 3 A consists of three columns labeled respectively, wireless device 100, server 140 and UDDI registry 170.
  • the process flow diagram Figure 3A illustrates the interaction between steps carried in the wireless device 100 and steps carried out in the UDDI registry 170.
  • the diagram of Figure 3 A begins with the wireless device 100 step 250 where a search handle is entered. Then, at step 252, query terms are entered. At step 254, the _find_business_ query is sent to the UDDI registry 170.
  • the UDDI registry conducts searches based on the Jind_business_ query and returns the businessList in step 255.
  • the flow then returns to the wireless device 100 and passes to step 256 wherein an item of the businessList is selected which typically is a businessEntity.
  • the businessEntity is then drilled down.
  • the flow then passes to step 258 in which the _find_service_ query is sent to the UDDI registry.
  • the flow then passes to the UDDI registry 170 where the _find service _ query is searched and the service list is returned in step 259.
  • the flow passes to the wireless device 100 where an item of the serviceList is selected which is a businessService.
  • the businessService is subsequently drilled down in step 260.
  • step 262 the _get serviceDetail _ query is sent to the UDDI registry. Then the flow passes to the UDDI registry 170 where the _get_serviceDetail_ query is responded to and the binding template is returned in step 263. Then the flow passes back to the wireless device 100 where in step 264, the serviceDetail is selected from the bindingTemplate and the accessPoint URL is stored in step 264.
  • Figure 3B illustrates a network process flow diagram of the interaction of the wireless device and the UDDI registry when carrying out a program to replay the UDDI registry search strategy. Figure 3B is divided into three columns, the wireless device column 100, the server 140 column, and the UDDI registry 170 column.
  • Figure 3B starts with the wireless device entering the replay UDDI registry search strategy wherein the search handle is entered in step 271. Then the process flows to step 272 where the search strategy is accessed in the user profile which corresponds to the search handle which was input in step 271. Figure 3B then proceeds through the remainder of the processes in a similar manner as that disclosed in Figure 3A.
  • Figure 3B discloses how the user is enabled to replay a prior UDDI registry search strategy. The user merely enters a previously used search handle into the wireless device and selects the replay option. The wireless device then accesses the UDDI registry search strategy from the user's stored profile corresponding to that search handle. This may be performed either at the wireless device 100 or, in the alternate embodiment in the server 140.
  • the search strategy includes information such as the businessEntity data and businessService data and bindingTemplate data that was found during the course of an earlier search of the UDDI registry 170.
  • This data contained in the UDDI registry search strategy (accessed from the stored profile) is then loaded as the data for each respective operand that would have been otherwise entered by the user.
  • the flow diagram of Figure 3B enables the user to automatically invoke a search strategy of the UDDI registry 170, that was used in the past.
  • Figure 4 is a functional block diagram of the knowledge engine server, showing the memory storing the application services software programs needed to perform the operations of an embodiment of the invention.
  • Figure 4 discloses the functional components of an exemplary knowledge engine server 140 arranged as an object model.
  • the object model groups the object oriented software programs into components that perform the major functions and applications in knowledge engine server 140.
  • the object model for memory 402 of knowledge engine server 140 employs a three-tier architecture that includes presentation tier 415, infrastructure objects partition 422, and business logic tier 414.
  • the object model further divides business logic tier 414 into two partitions, application objects partition 422 and data objects partition 426.
  • Presentation tier 415 retains the programs that manage the device interfaces to knowledge engine server 140.
  • presentation tier 415 includes network interface 420.
  • a suitable implementation of presentation tier 415 may use Java servlets to interact with WAP protocol gateway 120 via the hypertext transfer protocol ("HTTP").
  • HTTP hypertext transfer protocol
  • the Java servlets run within a request/response server that manages the exchange of messages between WAP protocol gateway 120 and knowledge engine server 140.
  • a Java servlet is a Java program that runs within a Web server environment.
  • a Java servlet takes a request as input, parses the data, performs logic operations, and issues a response back to WAP protocol gateway 120.
  • the Java runtime platform pools the Java servlets to simultaneously service many requests.
  • Network interface 420 accepts request messages from WAP protocol gateway 120 and passes the information in the request to visit object 428 for further processing. Visit object 428 passes the result of that processing to network interface 420 for transmission back to the WAP protocol gateway 120.
  • Network interface 420 may also use network adapter 406 to exchange data with another user device.
  • Infrastructure objects partition 422 retains the programs that perform administrative and system functions on behalf of business logic tier 414.
  • Infrastructure objects partition 422 includes operating system 425, and an object oriented software program component for database server interface 430, and system administrator interface 432.
  • Business logic tier 414 in Figure 4 includes multiple instances of visit object 428, 428', 428".
  • a separate instance of visit object 428 exists for each network interface 420 session.
  • Each visit object 428 is a stateful session bean that includes a persistent storage area from initiation through termination of the session, not just during a single interaction or method call. The persistent storage area retains information associated with the session.
  • WAP protocol gateway 120 sends a query message to knowledge engine server 140
  • the message is sent to network interface 420 to invoke a method that creates visit object 428 and stores connection information as a state in visit object 428.
  • Visit object 428 may, in turn, invoke a method in UDDI registry browsing application 440 to browse the UDDI registry 170.
  • Application 440 sends queries to the UDDI registry, as discussed above.
  • WAP protocol gateway 120 sends a search handle message to knowledge engine server 140
  • a message is sent to network interface 420 to invoke a method that creates visit object 428 and stores connection information as a state in visit object 428.
  • Visit object 428 may, in turn, invoke a method in replay UDDI registry search strategy application 442 to replay a prior search strategy.
  • the application 442 performs the replay method discussed above. Similar operations occur for applications 444, 446 and 448 in Figure 4.
  • Figure 4 A is a more detailed functional block diagram of the server, showing the knowledge engine 142.
  • the knowledge engine 142 includes a program which is shown in Figure 4A as a sequence of steps 1 through 13.
  • PROFILE & GOTO 6 [3] ACCESS UDDI REGISTRY WITH USER'S QUERY TO IDENTIFY WEB
  • server 140 Also provided in server 140 is the user data 146 which includes the user ID profile 230 which is discussed above. Since a plurality of users may make use of the server 140, there are a plurality of user profiles shown in Figure 4A, one for the user ID 230' having user profile 232' and another for the user ID 230" having user profile 232".
  • the server 140 of Figure 4 A also has a cache 144 which stores documents and lists which are obtained from the various websites 160 that have been interrogated by the user with the aid of the server 140.
  • Figure 4B is a flow diagram of the sequence of operational steps for the server 140 UDDI registry browsing program 170.
  • Figure 4B has three columns, the first column labeled user's wireless device 100, the second column labeled server 140, and a third column labeled UDDI registry 170 and web sites 160.
  • Figure 4B illustrates the interaction of the wireless device 100, the server 140, the UDDI registry 170 and the web sites 160, in accordance with an embodiment of the invention.
  • Figure 4B shows sending a query to the server, in step 401.
  • the user location included in wireless device 100 is sent in step 400.
  • the query request is then transmitted in step 401 to server 140.
  • the query is received from the user in step 402, and the process flows to step 403 where web sites are identified from the UDDI registry and the user's profile is updated.
  • the process in step 403 for identification of the web sites from the UDDI registry is the process which has been discussed above in connection with Figures 2A and 3 A.
  • the process then flows to step 410 in the UDDI registry 170, wherein the UDDI registry accesses the requested information in response to the queries sent from the server 140 to identify web sites. Step 410 then transfers the results of that search from the UDDI registry 170 back to the server 140.
  • the process flows to step 404 wherein the server has taken the information identifying the web sites received from the UDDI registry 170, and formulates a request to retrieve documents which is sent to the web sites 160.
  • the process then flows to step 411 where the web sites 160 receiving the request from the server 140, access their respective severs for the requested documents and then return the documents to the server 140.
  • the server 140 then sorts the documents into a list in accord with the user's profile, sorting the list into the order requested by the user, and filtering out any documents which the user is not interested, in accordance with the user's profile.
  • the process then flows to step 405 in which the documents are stored in the cache at the server, cache 144, and the list which has been sorted by the server 140, is returned to the user.
  • step 406 the process then flows to step 406 at the user's wireless device 100 where the sorted list received from the server 140 is presented to the user and the user can select from that list those documents desired to be reviewed.
  • step 406 the user's request for documents is then sent back to the server 140.
  • step 407 the server 140 accesses its cache 144 to retrieve those documents selected by the user in step 406, and then the server 140 returns the selected documents to the user's wireless device 100.
  • Step 407 then compiles the user's preferences in the user profile 230.
  • the server 140 can also update the user's preferences in the user's profile in step 409.
  • the process flows from step 407 to step 408 at the user's wireless device 100, where the user receives the selected documents.
  • a generic facility may be used to invoke required components in the terminal and in the server to implement end services for the user.
  • terminal-end software or components are not required to be resident in the user's terminal, and can automatically be retrieved from the server prior to service activation.
  • devices with limited memory capabilities or display sizes may still utilize web services and access runtime service installation and invocation.
  • Numerous security protocols may also be incorporated to ensure that user information is protected throughout the access/execution user iterations.
  • Figure 5 discloses an embodiment of the web services, wherein a user's wireless device 500 communicates to mobile network 501, which in turn is communicatively coupled to an Internet/Intranet network 502. It should be noted that the system of Figure 5 parallels the systems disclosed in Figures 1, 2 and 4.
  • Mobile network 501 is further coupled to service description & discovery service 506 and knowledge engine 505.
  • Knowledge engine 505 can access information from customer profile 503 in order to tailor searches and requests, described in greater detail above.
  • Knowledge Engine 505 can additionally serve to pre-process search queries, and post-process received data.
  • Service description & discovery service 506 is further connected to web service server 507, which has web services 504 resident therein. Each web service has a defined protocol interface for utilizing that service.
  • FIG. 6A illustrates an example of advanced search and result processing under an embodiment of the invention.
  • a user's device, or terminal 600 communicates through network 601 to knowledge engine server 602 and search engine server 603.
  • the terminal 600, knowledge engine server 602 and search engine server 603 are provided with platforms 615, 621, and 622.
  • Terminal 600 is provided with a plurality of software systems 604, 605, 606, that communicate through a search application programming interface (API) 610, as well as other API's 611 that may appear on the terminal 600.
  • API application programming interface
  • Software system 606 is shown as having a search algorithm 607, as well as multiple application algorithms 608, 609. The algorithms are configurable to communicate through a variety of API's specified by the device or by the user.
  • the algorithms in software system 606 may be duplicated, modified, increased or decreased in number in each software system (604, 605) residing in the terminal 600 and may be further altered to suit the user's needs.
  • search function 612 activates request pre-processing 614, which in turn establishes communication with search processor 616 in the knowledge engine server 602.
  • knowledge engine 617 processes the request to match a user/customer identity and profile, stored in customer profile database 618.
  • Knowledge engine 617 utilizes user profiles and preferences, as well as user terminal capabilities, to modify the search request and match the search with the customer profile information.
  • the modified request is then sent back to request pre-processing 614 and to search function 612.
  • the modified search request is then transmitted to search engine (or UDDI operator site) 619, located in search engine server 603.
  • search engine 619 may further initiate modifications to the request in accordance with customer profile 620, which is also located in search engine server 603.
  • Customer profile 620 contains additional information about a user from the search engine server side, and serves to complement pre-processing functions with post-processing capabilities.
  • search engine 619 provides back search results, the results may be tailored to match user profiles through transmission of the results between result post-processing 613, search processor 616, and knowledge engine 617.
  • the search API may alternately be set to function without pre- or post-processing functions in mobile terminals in which the service provider does not have knowledge engine functionality.
  • a user's device, or terminal 600 communicates through network 601 to knowledge engine server 602 and search engine server 603.
  • the terminal 600, knowledge engine server 602 and search engine server 603 are provided with platforms 615, 621, and 622.
  • Terminal 600 is provided with a plurality of software systems 604, 605, 606, that communicate through a search API 610, as well as other API's 611 that may appear on the terminal 600.
  • Software system 606 is shown as having search algorithm 607, as well as multiple application algorithms 608, 609. The algorithms are configurable to communicate through a variety of API's specified by the device or by the user.
  • the algorithms in software system 606 may be duplicated, modified, increased or decreased in number in each of the other software systems (604, 605) residing in the terminal 600 and may be further altered to suit the user's needs.
  • search function 612 is executed.
  • Search function 612 transmits a search request to search proxy 623, located in knowledge engine server 602.
  • Search proxy 623 is configured to handle pre- and post-processing features.
  • Search proxy 623 communicates with knowledge engine 624 to initiate request preprocessing functions.
  • Knowledge engine 624 recalls information from customer profile 618 from which a search is processed in accordance with the profile (see Figure 6A).
  • search proxy 623 forwards the search request to search engine 619, located in search engine server 603.
  • Search engine 619 is communicatively coupled to customer profile 620, wherein additional customer information is collected with the request for post-processing.
  • search engine 619 returns the profiled search results to search proxy 623, a post-processing function is performed on the search results to establish a user- tailored search before transmitting it back to search function 612.
  • Search agent 625 may also be implemented in the knowledge engine server 602.
  • Search agent 625 is communicatively coupled with the search proxy 623 and the customer profile 618.
  • Search requests from search function 612 that are sent to search proxy 623, wherein the search function is transmitted to the search agent 625 and stored.
  • Additional data such as time of search execution, type of search, user profile data, or additional search preferences may be additionally transmitted to the search agent 625.
  • search agent 625 obtains the search request and related information, search agent 625 may provide supplementary search functions, as well as conducting off-line searches.
  • Figure 6C illustrates another embodiment of the invention, where the user's terminal
  • WWW Server or WAP gateway 626 directly accesses WWW Server or WAP gateway 626, wherein WWW Server or WAP gateway 626 is communicatively coupled to knowledge engine 624 and/or search agent 625.
  • WWW Server or WAP gateway 626 is communicatively coupled to knowledge engine 624 and/or search agent 625.
  • system configuration of the present invention may be spread among numerous servers, or may be condensed into a single server.
  • Figure 6D illustrates another embodiment of the invention, wherein the user terminal performs requests or invocations for mobile web services.
  • the web services are temporarily downloaded to terminal 600, wherein server logic 642 in web service server 638 communicates with back office systems and business logic 648, located in remote server(s) 647.
  • Figures 7, 8A-B illustrate further details of the mobile web service system.
  • Requests are transmitted through invocation API 633, and may be subject to access restrictions in privacy control 636. Data stored in privacy profile database 634 would determine the access capabilities of a user.
  • invocation client 637 is activated to contact invocation server 644, shown in web service server 638.
  • invocation Client 637 communicates to invocation server 644 typically through a web service interface (not shown).
  • the web service interface can be a published API or protocol that has been requested by the mobile terminal.
  • the API protocol is configured to support web services that match the query.
  • Web service server 638 is loaded with numerous software systems (639-641), wherein service logic 642 resides. Service logic 642 accesses API's 643 and transmits them to invocation server 644.
  • Invocation client 637 is further enabled to provide device profile information to assist invocation server 644 in selecting suitable web services 645 for the mobile terminal 600.
  • Invocation server 644 will typically access various web service protocols from logic storage 646, or may dynamically create new web services for a particular instance.
  • Invocation server 644 may invoke service logic 642 locally in relation to the selected mobile web service, or may delay the invocation until the web service is accessed from terminal 600.
  • Figure 7 illustrates an embodiment of the invention, wherein terminal 700, with platform 708, communicates through mobile network 711 to web service sites 712.
  • the mobile network 711 may also include a public cloud UDDI.
  • Knowledge engine server 709, and customer profile 710 provides additional support to UDDI functionality as described above.
  • terminal 700 searches first for a web service server (from web service sites 712) that supports the web service capabilities of terminal 700. Once an appropriate web service server has been located, the service logic in a server from the web service sites functions to serve as the intermediary between terminal 700 and back office systems and systems logic (see Figure 6D).
  • a mobile web service 702 is downloaded or stored in terminal 700, the mobile web service 702 has a limited number of API's to utilize (704-706). This means that the web services in the mobile terminal are executed in a limited "sandbox".
  • the term "sandbox” refers to applications that are downloaded from a client or an enabled object access to operating system calls or to other resources. To compensate for this, mobile web services 702 access API's locally from the execution environment of terminal 700 (i.e., the sandbox). Enabled API's can automatically provide user data and profile information. The manner of providing API's, as well as the actual number of API's, may further be manipulated to serve the user's needs and minimize the complexities of data entry and transmission.
  • the API's can thus create web services for mobile domains that are user- friendly.
  • the information may be configured to an API to provide local or remote execution of applications that will utilize that information.
  • the information may be locally stored in the device, or alternately stored remotely at a network storage site.
  • new information e.g., "cookies”
  • Users may have the ability to review the information and choose to transmit or block information that is shared with other applications.
  • a personal API configuration can enable a mobile device to query for items like name, postal address, e-mail address or query for permission to utilize e-mail address in posting lists for new products.
  • a mobile web service can query the API when the user is registering for the first time to a service.
  • Privacy control features may then be used to prompt an end-user for permission to release such information. This enables an end user to be anonymous until registration, or until an m-commerce transaction is initiated. If registration to a specific web service is done, additional API may be provided to mobile web services to store the user registration ID to the mobile terminal, and enable a secure environment for the user. Furthermore, privacy controls may be used to enable automatic transmission to/from web services. Thus, web services in which the user is registered to may make an unsolicited "push" of mobile web services to the terminal when updated or new information becomes available.
  • terminal 700 could be initially engaged in a search to find organizations or companies that support the mobile web services of the terminal 700.
  • the terminal may additionally include other search criteria, such as those illustrated in Figures 1- IH.
  • the search may be done directly with UDDI or may utilize WAP or some other browser intermediate between terminal 700 and a portal capable of accessing a registry.
  • terminal 700 can initiate communication through an invocation client or browser (see Figure 6C-D) to the invocation web service in a server web service site 712.
  • terminal 700 can request mobile web services (e.g., "B2C e-Commerce Mobile Web Service") from the server invocation web service.
  • mobile web services e.g., "B2C e-Commerce Mobile Web Service
  • the server invocation web service will transmit to terminal 700 the appropriate web server instance (i.e., mobile web service), and will simultaneously activate the server side logic 642. Once transmitted, the mobile web service may be automatically or manually activated. Once activated, the web service will communicate with the appropriate API's in the terminal, and will subsequently connect with the service logic in the web service server 638 in the web service site 712.
  • the appropriate web server instance i.e., mobile web service
  • the mobile web service may be automatically or manually activated.
  • the web service will communicate with the appropriate API's in the terminal, and will subsequently connect with the service logic in the web service server 638 in the web service site 712.
  • SSL Secure Sockets Layer
  • SSL is known in the art and may be defined as a transport level technology for authentication and data encryption between a server and a browser.
  • SSL typically sends data over a "socket", which is a secure channel located at the connection layer existing in most TCP/IP applications.
  • Sites can use the protocol to obtain and/or manage confidential user information, such as credit card numbers.
  • the information is usually encrypted, and only the user's Web browser and the computer server at the other end running the web site have the key, and thus can understand what is being transmitted. Thus any unwanted outside parties would be prevented from understanding what the user was transmitting.
  • the mobile web service 702 may be configured to access API's in the terminal 700 execution environment, (i.e., the "sandbox") to determine which user data is transmitted.
  • each individual advertised web service can be modeled in a binding Template structure. Invocation of a web service can be performed based on cached binding Template data (discussed above).
  • a UDDI compatible browser may display more or less detail as the user searches through information. The following example steps through one iteration of discovering a remote web service:
  • Run program based on the knowledge of the specifications for the web service - this information may be obtained by using a tModel key information contained in the bindingTemplate for a service;
  • the program invokes the web service using the cached bindingTemplate information (as appropriate) and implements the required interface conventions as defined in the specification referenced in the tModel information.
  • Figure 8A discloses exemplary layers involved during the use of mobile web services.
  • Terminal 817 initiates a network connection or search 800.
  • Knowledge engine 801 supplements search 800with information retrieved from customer profile 802, and a transmission is made to UDDI cloud 803 located in description/discovery services layer 808.
  • Web services 804 communicate with service logic 805, which in turn communicates with back office systems 806.
  • the resulting invoked web service 807 is transmitted back to terminal 817.
  • Service delivery options include executable content (e.g., JAVA, WML Scripts, etc.) that are downloadable to terminal 817.
  • This executable content contains the "front-end" logic that would communicate with the "back end” logic located in the web server or business logic.
  • Mobile web services that have been discovered may be contacted by web service instance in the mobile terminal. This service instance may be either stored in the terminal semi-statically, or it may be dynamically loaded, as described below.
  • Figure 8B illustrates mobile web services with invocation capabilities.
  • Figure 8B has the same basic structure as that shown in Figure 8A, except that additional functions and connections are established with mobile web services layer 816.
  • Web services layer 809 is used to find web sites that support invocation web services 811 for terminal 817.
  • the downloaded invocation service 810 enables stored mobile web services 813 that are transmitted from web services 804.
  • Mobile web services 813 are associated with service logic 805 from web services 804 or can be associated with service logic from other remote sites (see Figure 6D).
  • Service logic 815 in mobile web services layer 815 handles terminal- side processing, and may be enabled to link directly to back office systems 816.
  • sites can be matched that have the capability to support both invocation web services 811 and certain mobile web services 813.
  • a search 800 for such a request for include a logical AND combination of terms querying "invocation web service support” and "mobile web service [X]", wherein "X" would represent the supported invocation mobile web service for the invocation web service.
  • Mobile web services layer 814 becomes active when mobile web service instance is received 814 and activated in terminal 817.
  • the mobile web services layer 816 becomes active when mobile web service instance 814 is received and activated in mobile terminal 817.
  • mobile web service instance 814 begins to communicate with server logic 805 in web services 804 to enable the services provided and supported by web service 804.
  • Terminal 817 may make a request for a supported mobile web service during or after making an initial search.
  • a matching service instance located in web services 804 will be identified to terminal 817 software.
  • the appropriate server acknowledges the presence of terminal 817 for further communications under a mobile web service environment.
  • terminal 817 may initiate a mobile terminal to search (e.g., UDDI registry) for all services that provide mCommerce _services and CD_reta.il and mobile_web_services.
  • All of the addresses returned to terminal 817 will be identified as being online CD retailers, wherein each service provider infrastructure is enabled to provide mobile web service software to mobile terminal 817.
  • each service provider infrastructure is enabled to provide mobile web service software to mobile terminal 817.
  • a request can be made to web services 804 to retrieve and download mobile web service mCommerce.
  • Mobile web service mCommerce is typically an executable application that will control and optimize user interfaces and terminal-side functions.
  • the mobile web service will then establish terminal- server functionality for invoking further services.
  • the executable content can now contact the server logic 815 to utilize mCommerce retail services.
  • the executable application may be temporarily downloaded (e.g., JAVA applet), or may reside permanently in a terminal.
  • the application may be sent statically, or may be dynamically generated to match requests made by various terminals. Once a server has prior knowledge of a terminal possessing mobile web services, the server may automatically push subsequent mobile web service instances to the terminal as needed.
  • the mobile web service (or web service instance) that is temporarily downloaded to the terminal coordinates with the service logic to communicate with the "eCommerce" site's back office systems and business logic.
  • the service provide may also tailor searches to direct selected portions of the search results to "preferred" service sites.
  • the resulting invention is applicable to virtually all digital communications networks, including wide area networks (WANs), metropolitan area networks (MANs), local area networks (LANs), and personal area networks (PANs).
  • WANs wide area networks
  • MANs metropolitan area networks
  • LANs local area networks
  • PANs personal area networks
  • the resulting invention is applicable to fixed station wireline networks, mobile wireless networks, and hybrid combinations of fixed station wireline networks communicating through wireless access points with mobile wireless networks.
  • the resulting invention is applicable to any mobile computing environment, including any wireless wide area network such as a cellular telephone network or any short range wireless system such as a wireless local area network or a wireless personal area network.
  • GSM Global System for Mobile Communication
  • DAMPS Digital Advanced Mobile Phone Service
  • PDC Personal Digital Cellular
  • GPRS General Packet Radio Service
  • W-CDMA Wideband GPRS
  • short-range wireless systems examples include the

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un système et un procédé destiné à permettre à un dispositif sans fil (100) de découvrir des services web mobile par accès à un registre UDDI (170) via un réseau sans fil (116) à l'aide d'instructions manuelles et programmées. Des profils utilisateurs stockés dans un dispositif sans fil (100) fournissent des raccourcis à des demandes en ligne ou hors ligne. Un registre UDDI (170) peut aussi être équipé d'un contenu exécutable afin de fournir des services additionnels au dispositif (100). Dans un autre mode de réalisation, un serveur (140) est prévu afin d'exécuter des instructions programmées supplémentaires pour interroger le registre UDDI (170) en réponse à des commandes du dispositif (100). Le serveur (140) peut être utilisé pour mettre en antémémoire des fichiers auxquels des sites web (160) ont accédé pour une retransmission sélective vers le dispositif sans fil (100).
PCT/IB2002/001585 2001-05-15 2002-05-08 Services utilisant le web mobile WO2002093289A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2002302871A AU2002302871A1 (en) 2001-05-15 2002-05-08 Mobile web utilizing services
EP02730556A EP1388032A4 (fr) 2001-05-15 2002-05-08 Services utilisant le web mobile

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/854,619 2001-05-15
US09/854,619 US7155425B2 (en) 2001-05-15 2001-05-15 Mobile web services
US7835302A 2002-02-21 2002-02-21
US10/078,353 2002-02-21

Publications (2)

Publication Number Publication Date
WO2002093289A2 true WO2002093289A2 (fr) 2002-11-21
WO2002093289A3 WO2002093289A3 (fr) 2003-02-13

Family

ID=26760446

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2002/001585 WO2002093289A2 (fr) 2001-05-15 2002-05-08 Services utilisant le web mobile

Country Status (3)

Country Link
EP (1) EP1388032A4 (fr)
AU (1) AU2002302871A1 (fr)
WO (1) WO2002093289A2 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2409736A (en) * 2003-12-30 2005-07-06 Ibm Ordering UDDI search results
EP1570384A2 (fr) * 2002-12-02 2005-09-07 Sap Ag Agent de services web
WO2006006017A1 (fr) * 2004-06-28 2006-01-19 Nokia Corporation Système et procédé d'enregistrement d'un produit et d'activation correspondante
GB2403049B (en) * 2002-03-22 2006-08-30 Citrix Systems Inc Methods and systems for providing access to an application
WO2006110998A1 (fr) * 2005-04-18 2006-10-26 Research In Motion Limited Systeme et procede de decouverte d'applications a composants
WO2006111002A1 (fr) * 2005-04-18 2006-10-26 Research In Motion Limited Systeme et procede destines a decouvrir des applications mobiles sans fil
CN1311380C (zh) * 2003-03-21 2007-04-18 英特尔公司 有助于从网络的移动设备中选择本地注册表主机的方法和系统
EP2023531A1 (fr) * 2007-04-28 2009-02-11 Huawei Technologies Co., Ltd. Procédé, dispositif, système, serveur d'application de terminal d'utilisateur pour sélectionner un service
US8538427B2 (en) 2005-07-28 2013-09-17 Telecom Italia S.P.A. Method for obtaining telecommunications services through a telecommunications terminal

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167441A (en) * 1997-11-21 2000-12-26 International Business Machines Corporation Customization of web pages based on requester type
US6173316B1 (en) * 1998-04-08 2001-01-09 Geoworks Corporation Wireless communication device with markup language based man-machine interface

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167441A (en) * 1997-11-21 2000-12-26 International Business Machines Corporation Customization of web pages based on requester type
US6173316B1 (en) * 1998-04-08 2001-01-09 Geoworks Corporation Wireless communication device with markup language based man-machine interface

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1388032A2 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2403049B (en) * 2002-03-22 2006-08-30 Citrix Systems Inc Methods and systems for providing access to an application
EP1570384A2 (fr) * 2002-12-02 2005-09-07 Sap Ag Agent de services web
CN1311380C (zh) * 2003-03-21 2007-04-18 英特尔公司 有助于从网络的移动设备中选择本地注册表主机的方法和系统
GB2409736A (en) * 2003-12-30 2005-07-06 Ibm Ordering UDDI search results
WO2006006017A1 (fr) * 2004-06-28 2006-01-19 Nokia Corporation Système et procédé d'enregistrement d'un produit et d'activation correspondante
WO2006110998A1 (fr) * 2005-04-18 2006-10-26 Research In Motion Limited Systeme et procede de decouverte d'applications a composants
WO2006111002A1 (fr) * 2005-04-18 2006-10-26 Research In Motion Limited Systeme et procede destines a decouvrir des applications mobiles sans fil
EP1872525A1 (fr) * 2005-04-18 2008-01-02 Research In Motion Limited Systeme et procede destines a decouvrir des applications mobiles sans fil
EP1872525A4 (fr) * 2005-04-18 2008-09-17 Research In Motion Ltd Systeme et procede destines a decouvrir des applications mobiles sans fil
US8538427B2 (en) 2005-07-28 2013-09-17 Telecom Italia S.P.A. Method for obtaining telecommunications services through a telecommunications terminal
EP2023531A1 (fr) * 2007-04-28 2009-02-11 Huawei Technologies Co., Ltd. Procédé, dispositif, système, serveur d'application de terminal d'utilisateur pour sélectionner un service
EP2023531A4 (fr) * 2007-04-28 2009-07-15 Huawei Tech Co Ltd Procédé, dispositif, système, serveur d'application de terminal d'utilisateur pour sélectionner un service
US8219688B2 (en) 2007-04-28 2012-07-10 Huawei Technologies Co., Ltd. Method, apparatus and system for service selection, and client application server

Also Published As

Publication number Publication date
EP1388032A4 (fr) 2006-08-30
AU2002302871A1 (en) 2002-11-25
EP1388032A2 (fr) 2004-02-11
WO2002093289A3 (fr) 2003-02-13

Similar Documents

Publication Publication Date Title
US7155425B2 (en) Mobile web services
US7249100B2 (en) Service discovery access to user location
US7324997B2 (en) Bookmark managing system and bookmark managing method
US20020103933A1 (en) Internet-access enabled device personalization
US6421716B1 (en) System for generating context-sensitive hierarchically ordered document service menus
US6272492B1 (en) Front-end proxy for transparently increasing web server functionality
US7047276B2 (en) Method and system for sharing data between wired and wireless platforms
US6480853B1 (en) Systems, methods and computer program products for performing internet searches utilizing bookmarks
JP2963087B2 (ja) アクセス機構、記憶媒体、データ処理システム、アクセス方法、ウェブ・ページ処理方法およびアクセス機構を設ける方法
US7526762B1 (en) Network with mobile terminals as browsers having wireless access to the internet and method for using same
US6625624B1 (en) Information access system and method for archiving web pages
CN101065947B (zh) Web服务注册和操作方法和系统
US20070240076A1 (en) System and Method for Visual History Presentation and Management
US7949702B2 (en) Method and apparatus for synchronizing cookies across multiple client machines
EP0953926A2 (fr) Procédé et dispositif pour connecter flexiblement en utilisant des alias
US20050182688A1 (en) Wish list
US20020103823A1 (en) Method and system for extending the performance of a web crawler
US20020120721A1 (en) Client capability detection in a client and server system
US20040073713A1 (en) Method, system, gateway, proxy and computer program for adding information to received content pages
KR20000064168A (ko) 인터넷을 통한 중고핸드폰 매매시스템 및 방법
WO2002093289A2 (fr) Services utilisant le web mobile
US7051085B1 (en) Remote saving method of the search information on the internet
US7359892B2 (en) Method and apparatus providing database inquiry services by dynamically creating intelligent links for refining a search
WO2007034585A1 (fr) Système d’enregistrement de journalisation d’accès et méthode d’enregistrement de journalisation d’accès
EP1168203A2 (fr) Système et méthode de présentation et de gestion de marque-pages visuels

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002730556

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002730556

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP