HK1138395B

HK1138395B - Persistent saving portal

Info

Publication number: HK1138395B
Application number: HK10104159.7A
Authority: HK
Inventors: 凯润‧安妮‧韦伯尔; 乔纳森‧特雷弗; 爱德华‧霍; 萨曼莎‧M‧特里波蒂
Original assignee: Jollify Management Limited.
Priority date: 2006-08-22
Filing date: 2007-08-20
Publication date: 2017-01-27

Description

Persistent saving portal

Technical Field

The present invention relates to the field of internet applications. In particular, the present invention relates to a method and system for collecting information on the internet.

Background

Today, if a user wants to save some information from the web, the user would have to go to the website, click through the web page, and then bookmark the page to save the information on the page. Essentially, the user has saved access to the web site. However, because the internet is a very short evolving environment, there are at least two problems associated with this approach. First, when the user needs the information again, the website may no longer exist. Second, even if the website still exists, the content of the website has changed so that information of interest to the user may no longer exist.

Another way to save some information from the web is to open a clipboard-like application such as microsoft Word, and then the user can select, copy, and paste the particular information of interest into the Word document. One drawback of this approach is that when this information is copied, other information related to the information of interest is not moved into the Word document. The user would have to manually type in citations, URLs, authors, and other contextual information related to the information obtained, which is a time consuming and tedious task.

Another approach is to use a program code similar to that described by Yahoo! The company provides my Web applications that allow users to save copies of Web pages containing information of interest. However, this approach preserves both information that is of interest to the user and information that is not of interest to the user. The user may only be interested in a particular portion of the page or a particular image on the page. Another disadvantage of this approach is that once the user saves the page, the user may have lost references, URLs, authors, and other contextual information related to the information obtained unless the user manually types in the information.

In the above case, one drawback is that the user is required to add metadata about the obtained information as a post-harvest action. There is no mechanism that allows users to collect and annotate information with metadata in real-time. In addition, there is no mechanism to save information in a structured manner. As a result, the user must organize and construct this information into a useful format after the information is collected. Therefore, there is a need to solve such problems of the prior art. In particular, there is a need for a persistent saving portal for collecting information on the internet.

Disclosure of Invention

In one embodiment, a method for collecting information on the internet includes parsing content of a web page to form a plurality of collectible objects, selecting one or more objects from the plurality of collectible objects, storing the one or more objects to one or more saving portals, annotating the one or more objects according to user specified data, and annotating the one or more objects according to implicit data of the one or more saving portals. The method further includes annotating the one or more objects automatically using the user-specified data without human intervention and annotating the one or more objects automatically using the implicit data of the one or more saving portals without human intervention.

Drawings

The aforementioned features and advantages of the invention, as well as additional features and advantages thereof, will be more clearly understood from the following detailed description of embodiments of the invention when read in conjunction with the accompanying drawings.

FIG. 1 illustrates a system for running a mapping application on a website according to an embodiment of the invention.

FIGS. 2A, 2B, and 2C illustrate a method of collecting information according to an embodiment of the present invention.

FIG. 3 illustrates a method of annotating collected information according to an embodiment of the present invention.

FIG. 4 illustrates an example of objects collected in each of the persistent saving portals of FIG. 2, according to an embodiment of the present invention.

Fig. 5 shows a mobile device running the above described application according to an embodiment of the invention.

FIG. 6 illustrates another set of persistent saving portals according to an embodiment of the present invention. Like numerals are used throughout the figures.

Detailed Description

Methods and systems for collecting information on the internet are provided. The following description is presented to enable any person skilled in the art to make and use the invention. Descriptions of specific embodiments and applications are provided only as examples. Various modifications and combinations of the examples described herein will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the examples described and illustrated, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Some portions of the detailed descriptions which follow are presented in terms of flowcharts, logic blocks, and other symbolic representations of operations on information that can be performed on a computer system. A procedure, computer executed step, logic block, process, etc., is here conceived to be a self-consistent sequence of one or more steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. These quantities may take the form of electrical, magnetic, or radio signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. These signals may be referred to at times as bits, values, elements, symbols, characters, terms, numbers, or the like. Each step may be performed by hardware, software, firmware, or a combination thereof.

FIG. 1 illustrates a system for running a mapping application on a website according to an embodiment of the invention. The system includes one or more internet content provider servers 102, a database 105, and one or more clients 104. Server 102 interacts with client 104 via communication network 103. The internet content provider server 102 is a host server operable to provide content to clients 104 via a network 103. One or more servers host websites and include map functionality. Database 105 is operable to store data provided by server 102 and/or client 104. The database may be in communication with server 102 or client 104 via network 103. The database may store data items included in the web page, such as maps and user information.

Alternatively, the server 102 may include databases, processors, switches, routers, interfaces, and other components and modules. Each server 102 may include one or more servers, or may be combined into a fewer number of servers than shown, depending on computing and/or distributed computing needs. The servers 102 may be located at different locations relative to each other. The databases may also be separately connected to the server 102. There may be more or fewer than two databases depending on computational and/or distributed computing requirements. The databases may be located at different locations relative to each other and the server 102.

Each client 104 may be a general purpose computer, such as a personal computer, having a Central Processing Unit (CPU), memory, input devices, output devices, and a display. Other computer system configurations, including internet appliances, hand-held devices, wireless devices, portable devices, wearable computers, cellular or mobile phones, Portable Digital Assistants (PDAs), multiprocessor systems, microprocessor-based or programmable consumer electronics, set top boxes, network PCs, minicomputers, and the like, may also be implemented as clients 104. Each client 104 may also implement analog and digital baseband circuitry, power management circuitry, a Radio Frequency (RF) transceiver, and battery interface and charging circuitry. Client 104 may include one or more applications, programming modules, and/or subroutines. By way of example, client 104 may include a browser application (e.g., internet explorer, etc.) and a Graphical User Interface (GUI) for accessing websites and webpages provided by server 102 and data stored in database 105. Clients 104 may be remote from each other, from server 102, and/or from database 105.

The network 103 is a communication network such as a Local Area Network (LAN), a Wide Area Network (WAN), or the internet. When network 103 is a public network, security features (e.g., VPN/SSL secure transport) may be included to ensure authorized access within the system.

Server 102 also includes a plurality of individual domains, such as shopping domain 106, news domain 108, My Web domain 110, map domain 112, and the like. A domain is a computer system implemented using different hardware and software for specific applications such as shopping applications, news applications, and mapping applications. The persistent saving portal application of the present invention runs on my Web domain 110, which my Web domain 110 uses HTML, CSS, JavaScript, widget engine and "asynchronous JavaScript and XML" (AJAX) to implement web2.0 functionality.

FIGS. 2A, 2B, and 2C illustrate a method of collecting information according to an embodiment of the present invention. As shown in FIG. 2A, a persistent saving portal collection 202 is displayed on a user's computing device along with a web page 204. The set of persistent saving portals 202 may include one or more persistent saving portals for storing and organizing information selected by a user. In this specification, a persistent saving portal is also simply referred to as a portal. In addition, the information saved in the persistent saving portal may also be referred to as one or more objects. In this example, each persistent saving portal is represented by a circle. In the expanded view of persistent saving portal collection 202, the three circles are labeled "item 1" 206, "item 2" 208, and "item 3" 210, respectively. The user may add a new saving portal by using the "AddaSavingPortal" button 211. The user may also modify the tags to represent the content of the objects stored in each portal. For example, the three circles representing the persistent save portal set 202 are labeled "MyWorkspace" 206, "Xmasides" 208, and "TriptoFrance" 210, respectively, in FIG. 2B. In this example, a portal is a collection of items that contain information to be used for personal consumption. In another embodiment, one or more of these portals may be destinations, such as a group mailing list or a group website. For example, when a user drops a map onto a saving portal specified for a particular group, the map may pass it on to the group collection of objects.

In FIG. 2B, as the user browses the web page 204, the user may be interested in saving a map 212 on the web page. To do so, the user may simply drag and drop the map to the relevant portal in the persistent saving portal collection 202. In this example, the map is related to "trip to france" and it is stored in the portal 210. Item 214 shows map 212 dragged to a portal labeled "trip to France". Note that any element or type of information on the web page may be saved, including but not limited to photos, text, graphics, video, sound, URLs, etc. It is also noted that the objects collected and annotated according to the present invention are not limited to objects on a website; the user may collect and annotate self-created information such as a car photo taken by his cell phone or a product barcode scanned by the user. These objects may be used to obtain other information of interest to the user.

The user may define a set of attributes to mark the collected objects. These properties are defined according to the collection of objects and can be edited or modified at any later time. The set of attributes may include keywords and/or symbols that the user may use to automatically annotate objects saved in a particular portal. For example, item 218 illustrates a user-specified annotation term, such as "Paris", "Honeynoon", for tagging objects stored in a "trip to France" portal. In addition, item 220 shows other implicit data, such as the user's name "Karon", information retention date "12.26.05", and data type "jpg". These data are automatically added to the information placed in the portal without human intervention. Note that other types of implicit data may be added including, but not limited to, time, place, file type, file size, access rights, etc. Both the user-specified term and the implicit term for each object are considered metadata for the object.

Note that when collecting or grabbing objects, there are several ways to construct and associate structured data. First, the URL associated with the object is analyzed to search for a unique object identification that can be used to subsequently query the backend database. For example, Yahoo! A transaction in the home may have a unique ID in its URL. If the URL is identified as belonging to Yahoo! Locally (from the domain name local. Yahoo. com), then an identification in the URL (such as id 1234567) may be used to identify the URL in Yahoo |! The local web service/database queries for more information about the transaction, such as phone number, operating time, customer or expert reviews, all from the URL associated with the transaction.

Second, the collected objects may contain microformats. Microformats are tags that allow semantic expressions in HTML (or XHTML) web pages. A gripper (gobbler) application may extract meaning from standard web pages marked with microformats. Existing XHTML (and HTML) standards allow semantics to be embedded or encoded within them. This is achieved by using specific HTML attributes. Adding microformats to standard HTML web pages enables machines to process HTML text and possibly load data into remote databases. This would enable programs such as the crawler application to find items such as contact information, events and comments on a web page.

Finally, information analysis techniques like LiveWords (http:// desktop. yahoo. com) or term extraction (http:// developer. yahoo. com) may be used to analyze the text in the grabbed objects to extract entities. The LiveWords feature provides a simple way for users to search the web for other information of interest to the user. Examples of entities include addresses, transactions, and companies, which in turn may be among other pairs such as Yahoo! Local like data sources (for searching for more transaction or corporate information) or in general web searches.

Such structured metadata can be applied in many ways (e.g., placing the crawled information on a map, or into a calendar) and can also be collected from the user's annotations or tags. For example, adding the text label "Palo alto" may be used to geo-tag objects collected in the saving portal with geo-coordinates of city Palo alto, which are identified by LiveWords as cities.

The crawler application enables the user to efficiently classify the objects he has collected and to efficiently access these objects using metadata that annotates the objects. After the objects have been collected, metadata may be added or deleted. For example, when a user adds a new term to an item, all objects contained within the item may be updated using the term. In another approach, a user may choose to selectively add certain terms to the metadata of certain objects. That would require more steps on the part of the user to select and add terms to the specific object specified. The metadata may be implemented in the user's environment as a tag cloud or in other visual ways to support browsing and querying the system for object and collection retrieval. As user collection of objects increases, the need for object and collection retrieval also increases. In addition, if a user's collection is published into a common repository, metadata enables clustering of similar projects or collections and supports retrieval from multiple sources.

In FIG. 2C, a persistent saving portal "French" 216 for collecting information about the French class 101 group is shown. The user may create multiple saving portals for each group to which the user belongs. In this example, item 219 shows user-specified annotation terms, such as "Reference", "Paristrip (Paris travel)" and "Travelguide" for marking objects stored in the "French class" portal. In addition, item 221 shows other implicit data, such as the user's name "Karon" and data type "jpg". These data are automatically added to the paris map 212 placed in the portal without human intervention. After the object is collected into the saving portal, it can be broadcast or distributed to the destination to which the user subscribes via an RSS (really simple syndication) feed or other means of transmitting information over the internet. The RSS file format is a family of Web feed formats specified in XML and used for Web syndication. RSS delivers its information as an XML file called "RSS feed", "Webfeed", "RSS stream", or "RSS channel". These RSS feeds provide a way for users to passively receive recently published content (such as text, web pages, sound files, or other media); this may be the complete content itself or just a link to the complete content, possibly with a summary or other metadata.

In a typical use case, content providers publish on their site seed links that end users can add to an aggregator (aggregator) program running on their machine. Periodically (typically every 5-10 minutes, although most aggregators make it user configurable), the aggregator asks all servers in its seed list if they have new content. If so, the aggregator either records the new content or downloads the new content. In this example, the map of paris is routed to the home page 222 of the group of french classes 101. On the main page of the French class 101 group, objects that have been saved and items created by the group members are shown. For example, the map of paris that the user has just collected is posted as item 224 with other objects.

FIG. 3 illustrates a method of annotating collected information according to an embodiment of the present invention. In fig. 3, the user interface window 302 displays the user-specified endorsement terms "paris, march, 12.26.05" for the portal "TriptoFrance (french travel)". User-specified annotation terms are entered into the editing domain by the user at the time of creation of the saving portal. Note that these user-specified annotation terms can be subsequently revised using an editing operation. In addition to text, any media asset can be added as an annotation to an object. In this example, the objects saved in the "trip to france" portal are marked with a user-defined icon (thumbnail 304 of the eiffel tower). As further shown in fig. 3, the user interface window includes a display switch 303. When the display switch 303 points downward, a representative view of the objects saved in the portal and the automatically created annotations are displayed. As shown in fig. 3, numerals 305, 306, 307, 308, and 309 represent five objects collected. Objects collected in a persistent saving portal get both user-defined annotations and implicit annotations. In one implementation, each object is unique in that it is assigned a unique identifier. A thumbnail 304 of the eiffel tower is added to each object. The user-defined icons allow better organization and annotation of the objects collected in the portal. In another embodiment, a picture of a person may be used as a user-defined icon to mark information received/collected from that person. Note that this support for non-textual metadata enables querying and retrieving of objects using their properties (like computer vision). For example, the ability to search for color attributes of an image or search for shapes of graphical objects may yield a different set of objects than simply searching for objects annotated with textual terms.

One aspect of the present invention is that when a portal is initially established, annotation data is automatically added to objects collected in the portal based on terms defined by the user (also referred to as user-specified terms) without requiring manual intervention after the initial establishment. Other implicit terms, such as user name, are determined from the owner or login of the computing device. The file type is determined from the data source or provided by the URL of the data. In addition, the computing device may provide other types of implicit data, such as date, time, access rights, and the like. User-specified and implicit annotation data (also referred to as metadata of the object) is made available to the user and can be added to the collected object when the object is transferred from one person to another.

In one embodiment, when an object is transferred from one person to another, the method accumulates new metadata to existing metadata that has been added to the object. Thus, the method assigns each object a set of unique metadata. In this way, the metadata supports citation and copyright requirements and context delivery. The user may use the metadata to find the original website where the object was collected and allow the user to retrieve other information from the website, if desired. The method of gathering and annotating information supports the creation of derivative works by users. This is because the method not only supports adding metadata to each object gathered, it also maintains the history, provenance, context, and location of the metadata.

FIG. 4 illustrates an example of objects collected in each of the persistent saving portals of FIG. 2, according to an embodiment of the present invention. As shown in FIG. 4, two portals, "Xmas planning" and "trip to France" are open. The objects in the "trip to france" portal are similar to those shown in figure 3. For the "Xmas plans" portal, the user-specified terms "2005, Christmas, family & friends" 402 are used to annotate objects. The "Xmas plans" portal includes three gift plans, namely a doll 404 to Klaire, a sail boat 406 to Mike, and a tent 407 to Anna. User-specified terms "2005, christmas, family & friends" and implicit terms "Karon" and "jpg" are automatically generated and added to each gift plan. The name of the gift recipient, e.g., Anna, is provided by the user as a user-specified term. In the portal "my work area", the user can store various information related to the work, including, for example, "objectdefinition (object of interest)". In this manner, the portal acts as a repository for storing collections of information about the user's work. Potentially useful and yet unstructured objects or ongoing plans may be collected in one or more such "object of interest" saving portals. These saving portals allow the user to collect objects that he has not decided how to use but that he thinks may be useful, and the user can then organize these objects into collections.

Note that the objects collected in the portal outweigh the summary of text and pictures. These objects may be used in conjunction with other information available to the internet content provider to provide additional information, goods, or services to the user. For example, objects collected in the "Xmas plans" portal may be linked to shopping domain 106 of FIG. 1. In this way, the user may be able to find merchants selling sailboats in the local area. In addition, information may be provided to the user to allow him to compare the characteristics and prices of different models of sailboats. Information about the sailboat accessories may also be provided to the user to further enrich the user experience of the sailboat. Such information may be displayed in some manner, such as a grid, or arranged according to a particular criteria (e.g., price) selected by the user. The manner in which the objects are collected and annotated enables information to be viewed in different intelligent ways.

For another example, conventionally when people see an address on a web page, they either manually cut-and-paste text into another document or manually write the address down on a piece of paper. Converting the address into an entry of an address book involves a number of tedious and time consuming steps. Using the present invention, the addition of metadata enables objects to provide relevant context. For example, the address object may link to a map field of an internet content provider to obtain a name, a phone number, a location, and driving directions to a business located at the address, or may link to a news field of the internet content provider to obtain additional information about the business located at the address.

Fig. 5 shows a mobile device running the above described application according to an embodiment of the invention. In this example, mobile device 500 is a palmOne device manufactured by Palm corporation of sonyvale, california. Note that the applications described above may run on different forms of user devices in addition to traditional desktop computing devices. This capability allows a user to have multiple points of access to information stored in the portal anywhere and at any time. To implement the ability to maintain a persistent saving portal, the objects contained in the persistent saving portal of a client device (e.g., desktop or mobile device) are saved and mirrored online in server 102 and database 105 of FIG. 1. As a result, the user may have universal access to the information saved in the persistent saving portal via the internet content provider's network.

The benefits of different user devices having universal access to a persistent saving portal can be illustrated by the following example. Assume that the user makes a travel schedule from his desktop computer at home and saves the itinerary in a persistent saving portal. When traveling, the user may use the mobile device to access the route saved in the persistent saving portal. For example, a user may obtain a hotel address with his mobile device. From the hotel address, the user may obtain map information and driving directions to the hotel through the map domain of the internet content provider. Thus, the ability to have universal access to the persistent saving portal enables the user to navigate to his destination. In one approach, users may harvest information into a holding portal using their mobile devices. For example, a user may scan a barcode, take a picture, or take a video, and immediately add the object to the portal with the metadata. The application may automatically apply the user's geographic location to assign implicit data to the photos in the saving portal, e.g., photos taken in paris will enter the french travel portal when the user is traveling in paris.

In one embodiment, the portal may be shared among multiple users. For example, user A and user B are working on different parts of the same project, and user B relies on user A's output to continue his work. Each time user a completes a task, he may place the task in the first shared portal so that user B may receive a notification of the status of user a and retrieve information from the first shared portal. Similarly, whenever user B completes a task, he may also place the task in the second shared portal so that user a may receive user B's status notification and continue to provide new tasks to the first shared portal. The ability to share the collected information may be implemented with a single object, with a group of objects, or with a collection of objects for all users in the saving portal. The user may define a customized sharing model for each portal, i.e., public, private, or shared only with my friends.

FIG. 6 illustrates another set of persistent saving portals according to an embodiment of the present invention. In the example shown in FIG. 6, thumbnail images 600 and corresponding enlarged images for nine portals are provided. Each portal may be used to store different information selected by the user, and each portal may be customized to support different user-specified annotations for different sets of information. Each persistent saving portal may be linked to other portals through links (represented by dashed lines) 602. A large number of persistent saving portals may be used to allow users to customize different sets of objects. Each portal provides a predefined area for seamlessly storing information in real time without requiring the user to stop and annotate each item saved in the portal. Each portal may be implemented as a widget and a user may combine multiple widgets to meet different needs and purposes. In an alternative approach, a user may use a single widget to implement multiple portals to meet different needs and purposes.

In one embodiment, the browser and information gathering application (also referred to as a crawler application) may be implemented using JavaScript running on a user's computing device (e.g., a desktop personal computer). The crawler application presents a user interface for collecting information, shown as one or more saving portals 206, 208, and 210 in fig. 2A, and uses Dynamic Link Libraries (DLLs) to listen for data to be collected on transmission control protocol/internet protocol (TCP/IP) ports. In this example, the web site provides or injects JavaScript into pages that use a bookmark let. A bookmark let is a small JavaScript program that can be stored as a URL in a bookmark in the most popular web browser or in a hyperlink on a web page.

The browser JavaScript creates a Flash object and parses the web page content into a plurality of collectible objects, thereby creating a collectible object that can be selected, dragged, and dropped to the saving portal. The user may capture data by dragging and dropping one or more collectible objects of the web page onto the saving portal, or by clicking an action button in the page next to the element. When grabbing the object, JavaScript in the web page uses the Flash object to establish a connection to the widget running on a predetermined TCP/IP port. The JavaScript then sends data about the crawled objects over the TCP/IP connection. The receiving gadget processes the object by annotating it with various attributes, such as time, date, etc. The receiving gadget then sends the object to a back-end server for storage and further processing. Further processing includes analyzing the source of the object to establish other collectible metadata about the object.

JavaScript in the gadget contacts the crawler service using xmlhttprequest (xhr) or other similar techniques to add objects to the appropriate user store. XHR is an API that can be used by JavaScript, JScript, VBScript, and other web browser scripting languages for: XML data to and from the web server is transferred and manipulated using HTTP to establish an independent connection channel between the page client and server side. The data returned from the XMLHttpRequest call may typically be provided by a back-end database. In addition to XML, XMLHttpRequest can be used to obtain data in other formats, such as JSON or even plain text. XMLHttpRequest is part of Ajaxweb development technology and is used by many websites to implement responsive and dynamic web applications.

In another embodiment, the crawler application includes only JavaScript running in the browser of the user's computing device. Similarly, in this example, the web site provides or injects JavaScript into pages that use a bookmark let. The browser JavaScript parses the web page, creating collectible objects that can be selected, dragged, and dropped into the saving portal. In addition, the browser JavaScript creates new page elements that present a user interface that includes one or more saving portals for collecting information. The user may capture data by dragging and dropping a collectible object of the web page to the grabber portion of the page, or by clicking an action button in the page next to the collectible object. When grabbing an object, JavaScript annotates the object with various attributes (such as time, date, etc.). The page JavaScript then sends the object to the back-end server for storage and further processing. Further processing includes analyzing the source of the object to establish other related metadata that may be collected. The JavaScript in the web page contacts the crawler service using XHR or other similar techniques to add the object to the appropriate user store.

In another embodiment, Yahoo! A widget engine may be used to implement the persistent saving portal of the present invention. One of ordinary skill in the art will appreciate that other implementations or other types of widget engines may be used to implement a persistent saving portal. Additionally, in the discussion that follows, methods of constructing and using widgets are described for a computing device running a Windows operating system. One of ordinary skill in the art will appreciate that similar implementations may be made for Macintosh, UNIX, or Linux operating systems.

Yahoo! The gadget engine (also referred to as "gadget engine" or "engine" in this document) uses extensible markup language (XML) to define gadgets and objects. The language forms a clear hierarchy for each object, the order in which the objects are drawn, and the order in which the properties of each object are associated. Examples of widgets are shown below:

<widgetdebug＝”on”>

<windowtitle-“SampleYahoo！Widget”>

<name>mainwindow</name>

<imagesrc＝”Images/Sun.png”name＝”sun1”>

<alignment>menter</alignment>

</image>

<textdata-“ClickHere”size＝”36”style＝”bold”>

<alignment>menter</alignment>

Sun1.opacity＝(sun1.opacity/100)*90

</onMouseUp>

</text>

</window>

</widget>

whenever the user clicks on the text representing "click here", the widget reduces the opacity of the image by 10%. The sample gadget is used to illustrate several points. First, the structure of the widget uses the symmetric language XML so that each object specifier (e.g., < text >) has a corresponding terminator (</text >). Within these pairs of specifiers and terminators, attributes of the object are defined, such as screen position, alignment, etc. Second, objects defined in XML may be manipulated in JavaScript. Third, the name of the object starts with a letter. Only letters, numbers and underlining are allowed for the name. The XML description of the gadget is stored in a file with the extension kon. In fact, gadgets may have many image and text objects, multiple sections of JavaScript, and new objects may be created at runtime using JavaScript to implement complex functionality. The following sections describe various embodiments of techniques and code for creating new widgets.

There are two types of notation from the XML syntax, which are:

<image>

<src>images/image.png</src>

<name>myImage</name>

</image>

or:

<imagesrc＝”images/image.png”name＝”myImage”/>

the user can mix and match these two markers as follows:

<imagesrc＝”images/image.png”>

<name>myImage</name>

</image>

an entity is an XML structure that allows a user to specify characters via a specialized escape order. Consider that some characters remain for parsing the XML grammar. Symbol & is used as the start of the entity escape (and for this reason is also a reserved character). The standard set of entities is used to represent XML-specific characters:

&amp；&

&quot；”

&apos：’

&lt<

&gt>

the user may also use the entity to specify characters in terms of its unicode code points:

&#32；<spacecharacter，decimal>

&#x20；<spacecharacter，hex>

since the XML engine looks for < and > symbols to tag blocks of XML data, the JavaScript engine needs to replace these symbols with & it and & gt, respectively. For example:

If(x&lt；5)

displayResults()；

</onMouseUp>

alternatively, the user may use XML annotations to hide JavaScript code from the XML engine, as is typically done in HTML:

＜！-

If(x＜5)

displayResults()；

//--

</onMouseUp>

in another approach, the user may use the CDATA section as follows:

<！[CDATA[

If(x＜5)

displayResults()；

]])

</onMouseUp>

these alternatives make the code easier to read. In another approach, a user may place the XML parser in a "strict schema," which enforces the rules of XML in a manner that the parser would not normally do so. To support strict schema, the following lines are added to the top of the XML file:

<？konfabulatorxml-strict＝”true”？>

in strict mode, the following aspects of the program are performed: 1) all attribute values are placed in quotation marks; 2) stray "&" characters are not allowed in the plain text section; 3) evaluating the entity (something starting with "&") within the attribute values; 4) no double dashed line ("-") is allowed within the annotation. For this reason, the code is preferably placed within the CDATA block; and 5) if an external file is included, there is no need to replace the entity, e.g., & lt in the file.

The location of the file path in the gadget engine relative to the XML file. This means that file references without directories (e.g., main. js) will be searched in the same directory as the XML file, while file references with directories (e.g., javascript/main. js) will be searched in designated subdirectories of the directory where the XML file resides. Preferably, absolute paths (e.g., start-up paths) are not used because the disk layouts of different computers may be very different.

In Windows machines, the files that make up the gadgets are stored in widget files. This is a standard ZIP file that has changed its extension to a widget. Widget engines of the Windows version can read the packaged widget file. This is also the format that is selected when creating the cross-platform gadget. In one example, the widget package has the following structure:

myWidget.widget

Contents

myWidget.kon

Resources

kon files contain the actual gadget code (similar to the sample gadget in the section above). In one implementation, the. kon file is contained in a content file. The user may have resources, such as pictures, placed in them. Typically, the resource will be placed in the Resources folder, as indicated above.

If the user does not use the widget transformer and instead decides to compress the file manually, on a Windows computer this can be done by right clicking on the widget folder and creating a ZIP file from it. It should be noted that a user does not need to create a packaged widget file for testing each time the user makes a change when developing a widget. The user may double click on the kon file to achieve the same effect.

Note that the widget package should not be modified at runtime. In other words, a widget package should not be used to store information in itself. While many gadgets use preferences to store their settings, a gadget may store information in its own package. In addition, when the gadget engine runs a compressed gadget, it first decompresses it to a dedicated location and then runs the gadget from there. This decompression occurs each time the widget is run, so if the information is stored in the widget's decompressed package, it may be overwritten. To accommodate gadgets that require storage of persistent data, the system gadget DataFolder path may be used to store persistent information for the gadget.

In yet another embodiment, the gadget engine may support an uncompressed flat file format. When the flat file format is uncompressed, the size of the widget is larger than that of the widget in the zip format. Since images occupy a large portion of the widget size, the text file is typically uncompressed since images are typically already in compressed format (PNG, JPG), increasing on average by about 15%. The advantage of compressing the files is that the files do not need to be stored in RAM until they are actually needed, since the files are file mapped. By using this new format, the time for launching the widget application is reduced.

When a widget uses a flat file format, items that may have been wrapped with the widget, such as Dynamic Link Libraries (DLLs), may not be used unless a new API (widget) is used to extract the file from the flat file widget to a location in the file system. One exception is that the sound file played through the play () function may work without any changes.

This section discusses how gadgets operate and certain problems that need to be solved. When the gadget is opened, it runs as a separate process. This is done to ensure that one widget does not affect the remaining widgets that the user can use. The zip-formatted gadget is decompressed to a specialized location (C:/documentsandSettings/< user >/LocalSettings/applicationData on a PC). The uncompressed gadget is run from where it is located. For this reason, there is no dependence on where the gadgets are located. Once the kon file is located in the widget, the current directory is set to the directory where the kon file is located. So, for example, if a kon file is in the Contents folder, the current working directory will be Contents. This allows the relative path to Resources to work correctly. A kon file, for example, references an image as Resources/image1.png if its image is in the Resources folder in the Contents folder.

When a kon file is located and the current directory is set, the file is parsed and the objects defined therein are created. After everything is successfully created, the onLoad handler is invoked. The gadget then runs an initialization routine. Note that the onLoad handler is typically executed before the widget is made visible. In other words, many gadgets begin to have their windows set to hidden and become visible upon completion of execution of the onLoad handler. After the onLoad handler is successfully run, the gadget starts and runs. Note that the next time the widget runs, it decompresses again. For this reason, there is no reliance on storing information in the widget package. Instead, it is preferable to store the information in the widget's DataFolder, as previously discussed.

The gadget engine knows which gadgets can be automatically opened. The next time the widget engine starts, it automatically reopens any widgets that were running when the widget engine was last shut down.

Actions in gadgets are important because they are where a user defines how the gadget behaves when the user interacts with the gadget. In one implementation, the action is specified by setting the action on certain JavaScript text. The text is evaluated and run when the user clicks, for example:

Print(“hello”)；

</onMouseUp>

however, there are at least two limitations: 1) the user may not use the JavaScript 'this' object that normally references the object for which the action is being run; and 2) if the user has multiple objects of the same code, he may have to copy JavaScript and change the object's name to represent each object to which he has added code.

To fix these restrictions, the gadget engine supports the correct JavaScript functions for these actions. For example, no parameters are sent to the action. Additionally, the onMouseUp handler may receive the x and y coordinates of the mouse instead of checking the system. To use a function, the user can either use the function in XML (by using attributes) or set properties on the function to call in JavaScript, as follows:

<！--InXML-->

<onMouseUpfunction＝”myMouseUp”/>

// in Javascript

myImage.onMouseUp＝myMouseUp；

And somewhere in the JS code, the function needs to be defined:

functionmyMouseUp()

{

print(this.opacity)；

}

in an XML description, the user may set the < name > property. This defines a global JavaScript object that can be created and bound to an object of which the name is a part. For example, the code < windows ═ mainWindow "./> creates JavaScript with the name mainWindow that is variable on the global scale. Note that all names need to be unique. Additionally, because these names are used internally to track objects, they cannot be changed. The gadget engine does this by making all features read only. When a user creates an object at runtime using JavaScript, the object is given a general name, such as Image 001.

Some provisions are made for commissioning gadgets. There is an XML tag "debug" that the user can set to "on" for debugging purposes. When the "debug" flag is set to on, the debug output window will open when the widget is started. Calls to log () or print () in the JavaScript code are routed to the debug window. Any errors encountered within the gadget engine are also reported in this window. Note that the debug window will not open unless the debug flag is set to on.

When a widget is developed, it is preferable to turn on the debug flag so that it can notify the user of an error that occurs while the widget is running. For example, if the property is misspelled, the output window notifies the user of the error, along with notifying where the problem can be found in the code.

There are two types of security windows that may be present in the gadget engine. The first is to run/modify the window for the first time. When a widget that was not previously seen by the widget engine is run for the first time, a window appears to inform the user that a new widget is about to be opened and let the user confirm the action. This is to prevent gadgets that may just run when the user is not aware of it. Also, if the user allows the widget to run and then the widget is modified, another window appears the next time the widget is started, informing the user of the modified widget. Again, the user can confirm or deny the request to launch the modified widget.

If the user is in the process of debugging the widget, the user may turn on the debug mode, which may inhibit the initial execution/modification of the security window. Thus, the user is not interrupted each time the user modifies the code and reloads the gadget.

The second type of window is a 'sandboxed' window. In one approach, the sandbox action involves the user logging into his internet content provider account. When the widget first attempts to log into his account, a window will appear to alert the user to the fact and ask if the widget should be given rights to use the user data on the account.

It will be appreciated that the above description for clarity has described embodiments of the invention with reference to different functional units and processors. It will be apparent, however, that any suitable distribution of functionality between different functional units or processors may be used without detracting from the invention. For example, functions illustrated to be performed by separate processors or controllers may be performed by the same processor or controllers. Hence, references to specific functional units are to be seen as references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.

The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. Alternatively, the invention may be implemented partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.

One skilled in the relevant art will recognize that many possible modifications and combinations of the disclosed embodiments can be used while still using the same basic underlying mechanisms and methods. The foregoing description, for purpose of explanation, has been written with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to explain the principles of the invention and their practical applications, and to enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. A method of collecting information on the internet, comprising:

parsing, by a computing device, content of a web page on a network to form a plurality of collectible objects;

receiving, by the computing device, a selection of one or more objects of the plurality of collectible objects;

storing, by the computing device, the one or more objects to one or more saving portals;

automatically annotating the one or more objects using user-specified data without manual intervention;

automatically annotating the one or more objects without manual intervention using implicit data of the one or more saving portals, the implicit data comprising social data associated with the one or more objects;

extracting, by the computing device, at least one entity based on the data associated with the one or more objects; and

causing, by the computing device, display of the one or more objects with the at least one entity.

2. The method of claim 1, wherein the one or more objects selected from the web page comprise one or more pieces of information selected from the group consisting of text, audio, video, graphics, images, and URLs.

3. The method of claim 1, wherein the one or more objects include information about a person, including job title, professional association, contact information, and areas of expertise.

4. The method of claim 1, wherein the social data associated with the one or more objects includes comments, ratings, and a number of times the one or more objects are viewed.

5. The method of claim 1, wherein the implicit data comprises one or more items selected from the group consisting of:

the date the object was created;

a location where the object was created;

the date the subject was collected;

a title of the object;

an original owner of the object;

an intermediate owner of the object; and

a URL to the original owner's web page.

6. The method of claim 1, further comprising:

organizing the one or more saving portals according to user-defined parameters to form a set of objects; and

linking the set of objects to additional information on the network, wherein the additional information includes shopping, news, and map information.

7. The method of claim 1, wherein storing the one or more objects further comprises:

storing the one or more objects on the network; and

sharing the one or more objects across a plurality of user devices.

8. The method of claim 7, wherein the sharing the one or more objects provides access to the one or more objects for a plurality of user devices including a stationary computing device and a mobile device.

9. The method of claim 1, wherein the step of using implicit data to automatically annotate the one or more objects further comprises, without manual intervention:

identifying a source of the one or more objects; and

providing copyright information of a source of the one or more objects.

10. The method of claim 1, further comprising:

retrieving additional information using the data associated with the one or more objects; and

using the retrieved additional information to construct structured metadata for the one or more objects.

11. The method of claim 1, further comprising:

sending one or more objects from the one or more saving portals to a destination, wherein the destination comprises at least one item selected from the group consisting of a group mailing list and a group website.

12. An apparatus for collecting information on the internet, comprising:

means for parsing the content of a web page on a network to form a plurality of collectible objects;

means for receiving a selection of one or more objects of the plurality of collectible objects;

means for storing the one or more objects to one or more saving portals;

means for automatically annotating the one or more objects using user-specified data without manual intervention; and

means for automatically annotating the one or more objects without manual intervention using implicit data of the one or more saving portals, the implicit data comprising social data associated with the one or more objects;

means for extracting at least one entity based on data associated with the one or more objects; and

means for causing the one or more objects to be displayed with the at least one entity.

13. The apparatus of claim 12, wherein the one or more objects selected from the web page comprise one or more pieces of information selected from the group consisting of text, audio, video, graphics, images, and URLs.

14. The apparatus of claim 12, wherein the one or more objects include information about a person including job title, professional association, contact information, and areas of expertise.

15. The apparatus of claim 12, wherein the social data associated with the one or more objects includes comments, ratings, and a number of times the one or more objects are viewed.

16. The apparatus of claim 12, wherein the implicit data comprises one or more items selected from the group consisting of:

the date the object was created;

a location where the object was created;

the date the subject was collected;

a title of the object;

an original owner of the object;

an intermediate owner of the object; and

a URL to the original owner's web page.

17. The apparatus of claim 12, further comprising:

means for organizing one or more saving portals according to user-defined parameters to form a set of objects; and

means for linking the set of objects to additional information on the network, wherein the additional information includes shopping, news, and map information.

18. The apparatus of claim 12, wherein the means for storing the one or more objects further comprises:

means for storing the one or more objects on the network; and

means for sharing the one or more objects across a plurality of user devices.

19. The apparatus of claim 18, wherein means for sharing the one or more objects comprises means for providing access to the one or more objects for a plurality of user devices including a stationary computing device and a mobile device.

20. The apparatus of claim 12, wherein means for automatically annotating the one or more objects using implicit data without manual intervention further comprises:

means for identifying a source of the one or more objects; and

means for providing copyright information of a source of the one or more objects.

21. The apparatus of claim 12, further comprising:

means for retrieving additional information using the data associated with the one or more objects; and

means for constructing structured metadata for the one or more objects using the retrieved additional information.

22. The apparatus of claim 12, further comprising:

means for sending one or more objects from the one or more saving portals to a destination, wherein the destination comprises at least one item selected from the group consisting of a group mailing list and a group website.

23. The method of claim 1, wherein the at least one entity is a member selected from the group consisting of an address, a transaction, and a company.

24. The apparatus of claim 12, wherein the at least one entity is a member selected from the group consisting of an address, a transaction, and a company.