Abstract:
A system receives an Extensible Markup Language (XML) feed, where the XML feed includes a reference to secure content. The system downloads secure content from a remote location based on the reference included in the XML feed.

Description:
BACKGROUND 
     1. Field of the Invention 
     Implementations described herein relate generally to data exchange and, more particularly, to providing secure feeds of data. 
     2. Description of Related Art 
     Extensible Markup Language (XML) is a simple, very flexible text format originally designed to meet the challenges of large-scale electronic publishing. XML is playing an increasingly important role in the exchange of a wide variety of data on the World Wide Web (WWW). XML creates common information formats and shares both the format and the data on the World Wide Web, intranets, and elsewhere. A number of XML formats have been designed, including Really Simple Syndication (RSS) and Atom. 
     Really Simple Syndication (RSS) is a lightweight XML format designed for sharing headlines and/or other Web content between sites. RSS includes a family of XML file formats for web syndication used, for example, by news websites and weblogs (“blogs”). The technology of RSS allows Internet users to subscribe to websites, whose content typically changes regularly, that provide RSS feeds. To use this technology, site owners create or obtain specialized software (e.g., a content management system) which, in the machine-readable XML format, presents new content in a list, giving a line or two of text from each item of content. The RSS formats provide web content or summaries of web content. This information is delivered as an XML file called an XML feed, RSS feed, webfeed, RSS stream, or RSS channel. In addition to facilitating syndication, RSS allows a website&#39;s frequent readers to track updates on the site using an aggregator. 
     SUMMARY 
     According to one aspect, a method may include receiving Extensible Markup Language (XML) feed data from an XML feed provider, where the XML feed data includes a reference to secure content. The method may further include sending authentication data to a network location associated with the reference and receiving secure content from the network location based on the user authentication data. 
     According to another aspect, a method may include sending an Extensible Markup Language (XML) feed, containing a reference to secure content, to an XML aggregator. The method may further include receiving a request for the secure content from the XML aggregator and sending an authentication request to the XML aggregator. The method may also include receiving authentication data from the XML aggregator and uploading the secure content to the XML aggregator based on the authentication data. 
     According to a further aspect, a method may include receiving an Extensible Markup Language (XML) feed, where the XML feed includes a reference to secure content. The method may further include downloading secure content from a remote location based on the reference included in the XML feed. 
     According to an additional aspect, a method may include sending an Extensible Markup Language (XML) feed, that relates to secure content and contains a reference to the secure content, to an XML aggregator. The method may further include receiving authentication data associated with a user desiring access to the secure content and uploading the secure content to a client associated with the user based on the authentication data. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with the description, explain the invention. In the drawings, 
         FIG. 1  is an exemplary diagram of an overview of an implementation of the invention; 
         FIG. 2  is an exemplary diagram of a network in which systems and methods consistent with principles of the invention may be implemented; 
         FIG. 3  is an exemplary diagram of a client or server of  FIG. 2  according to an implementation consistent with principles of the invention; 
         FIGS. 4A through 4B  are a flowchart of an exemplary process for receiving a secure XML feed at an XML feed aggregator consistent with principles of the invention; 
         FIG. 5  is a diagram of un-secure content of XML feed entries being presented at an XML feed aggregator consistent with principles of the invention; 
         FIG. 6  is a diagram that illustrates user authentication prior to provision of the secure XML content to an XML feed aggregator consistent with principles of the invention; 
         FIG. 7  is a diagram of XML un-secure content and selected secure content being presented at an XML feed aggregator consistent with principles of the invention; and 
         FIG. 8  is a flowchart of an exemplary process for authenticating a user and providing secure content to the user subsequent to user authentication. 
     
    
    
     DETAILED DESCRIPTION 
     The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. 
     Consistent with aspects of the invention, XML feeds of secure, private or sensitive content is provided to users. An XML feed, consistent with principles of the invention, may include un-secure content and an associated link (e.g., a Uniform Resource Locator (URL) associated with the network location at which the secure content is stored) to secure content. Upon receipt of the XML feed, the XML aggregator or client may extract the link from the XML feed and transmit a request to the link requesting a download of the secure content. The XML aggregator may additionally transmit authentication data to the link. Based on the download request, and possibly the authentication data, the XML aggregator or client may receive the download of the secure content from the network location associated with the link. 
     A “document,” as the term is used herein, is to be broadly interpreted to include any machine-readable and machine-storable work product. A document may include, for example, an e-mail, a website, a business listing, a file, a combination of files, one or more files with embedded links to other files, a news group posting, a blog, a web advertisement, a digital map, etc. In the context of the Internet, a common document is a web page. Documents often include textual information and may include embedded information (such as meta information, images, hyperlinks, etc.) and/or embedded instructions (such as Javascript, etc.). A “link,” as the term is used herein, is to be broadly interpreted to include any reference to/from a document from/to another document or another part of the same document. 
     OVERVIEW 
       FIG. 1  illustrates an exemplary overview of an implementation of the invention that provides a secure XML feed to a XML feed aggregator  100  from an XML feed provider  110 . In the implementation illustrated in  FIG. 1 , XML feed provider  110  requires authentication prior to secure content being sent to XML feed aggregator  100 . 
     To receive content via an XML feed, XML feed aggregator  100  first sends an XML feed poll  120  to XML feed provider  110  to determine whether XML feed provider  110  is storing new, or changed, content. If XML feed provider  110  is storing new, or changed, content, XML feed provider  110  transmits an XML feed  130  to XML feed aggregator  100 . XML feed  130  may include un-secure XML content  134  and a link  138  to secure XML content. The un-secure content may include any type of content which is not considered by an operator of XML feed provider  110  as secure, private or sensitive. In one implementation, un-secure XML content  134  includes information (e.g., a snippet) associated with the secure XML content. The link  138  to secure content may include any type of reference to stored content that is considered by an operator of XML feed provider  110  as secure, private or sensitive. Link  138  may include, for example, a URL associated with a network location at which the secure content is stored. The secure content may include any type of content, such as, for example, a digital image, text, text and digital image, a video file, etc. XML feed aggregator  100  may present the un-secure content of the XML feed  130  to a user (not shown). 
     After receiving XML feed  130 , XML feed aggregator  100  may use the link  138  contained in XML feed  130  to transmit a secure content request  140  to XML feed provider  110 . The secure content request  140  may be sent in response to the user at XML feed aggregator  100  selecting an image element associated with the secure content from a display of XML feed data (not shown). In response to the secure content request, XML feed provider  110  may send a user authentication request  150  to the link  138  associated with the network location at which the secure content is stored. The user authentication request may request that the user at XML feed aggregator  100  provide user data that will authenticate the user. 
     In response to user authentication request  150 , XML feed aggregator  100  obtains data  160  that authenticates the user (e.g., by having the user enter identification information, such as a username and password). XML feed aggregator  100  then sends user authentication data  160  to XML feed provider  110 . After receiving user authentication data  160  that corresponds to the secure content request  140 , and validation of the user authentication data, XML feed provider  110  may transmit the secure content  170  to XML feed aggregator  100 . Secure content  170  may include any type of secure, private or sensitive data, including, for example, textual data, image data, etc. As one example, in Google AdWords, secure content  170  may include a campaign summary (e.g., a spreadsheet-like table of text) associated with a user&#39;s ad campaign that is hosted by Google. Secure content  170  may, in some implementations, only be accessible to users who pay for the access (e.g., subscribers). Thus, consistent with some implementations of the invention, user authentication data only has to be supplied to XML feed provider  110  at the time that XML feed aggregator  100  attempts to render secure XML content (e.g., when the user at XML feed aggregator  100  selects the image element associated with the secure content) or to render the un-secure XML content associated with the secure XML content. 
     Exemplary Network Configuration 
       FIG. 2  is an exemplary diagram of a network  200  in which systems and methods consistent with the principles of the invention may be implemented. Network  200  may include multiple clients  205  connected to one or more servers  215  or  220  via a network  225 . Two clients  205  and two servers  215  and  220  have been illustrated as connected to network  225  for simplicity. In practice, there may be more or fewer clients and servers. Also, in some instances, a client may perform one or more functions of a server and a server may perform one or more functions of a client. 
     Clients  205  may include client entities. An entity may be defined as a device, such as a personal computer, a wireless telephone, a personal digital assistant (PDA), a lap top, or another type of computation or communication device, a thread or process running on one of these devices, and/or an object executable by one of these devices. Clients  205  may implement XML feed aggregators  100  that retrieve portions of stored document content (e.g., syndicated web content) from an XML feed provider  110  that is supplied in the form of a web feed (e.g., RSS, Atom, or other XML formats), and that are published, for example, by blogs, podcasts, vlogs, mass media websites, etc. XML feed aggregators  100  may include desktop aggregators (e.g., News Reader, NetNewsWire, FeedDemon, Fuzzy Duck, Liferea, FeedReader) or “built-in” aggregators (e.g., Safari, Opera Web Browser, Mozilla Thunderbird, Mozilla Firefox, Internet Explorer 7, My RSS Toolbar, Google Toolbar) that can receive and aggregate XML feeds from XML feed provider  110  for presentation to users. 
     Server(s)  215  may include one or more server entities that store, update, and maintain document content. Such content may include data related to published news stories, products, images, or any other type of data that may be published by blogs, podcasts, vlogs, mass media websites, etc. For example, server(s)  215  may store, update or maintain news stories from any type of news source, such as, for example, the Washington Post, the New York Times, Time magazine, or Newsweek. As another example, server(s)  215  may store, update, or maintain data related to specific products, such as product data provided by one or more product manufacturers. As yet another example, server(s)  215  may store, update, or maintain data related to other types of web documents, such as pages of web sites. Furthermore, server(s)  215  may store documents having any type of data content (e.g., daily ad spending to an advertiser advertising on Google AdWords, stock prices, back links to a web site, security warnings when a user tries and fails to log onto a web site too many times, code submissions to a source control system, etc.) that may also be provided as an XML feed by XML feed provider  110 . Server(s)  215  may include, or have associated with it, a XML feed provider  110 . XML feed provider  110  may provide XML feeds (e.g., in RSS, Atom, or other XML formats), containing portions of stored document content, to XML feed aggregators  100 . Only one server  215  and XML feed provider  110  is shown in  FIG. 2  for illustrative purposes. Network  200  may, however, include multiple servers  215  with their associated XML feed providers  110 . 
     Server  220  may include a server entity that can store or maintain portions of documents aggregated by an associated XML feed aggregator  100 . XML feed aggregator  100 , associated with server  220 , may retrieve portions of stored document content (e.g., syndicated web content) from one or more XML feed providers  110  associated with one or more servers  215  that is supplied in the form of an XML feed (e.g., RSS, Atom, or other XML formats). XML feed aggregator  100 , associated with server  220 , may, thus, aggregate XML feeds from multiple different XML feed providers  110 . XML feed aggregator  100 , associated with server  220 , may include a web based aggregator (e.g., NewsIsFree, BlogLines, HyperSuper, Rojo, AlmondRocks, NewsGator, Xprssit, Newsvine) that aggregates XML feeds and permits users at clients  205  to access and read them in their browsers. XML feed aggregator  100 , associated with server  220 , may further include email based aggregators that aggregate XML feeds and permit users at clients  205  to receive the content of the feeds in their email clients. Server  225  may further include its own XML feed provider  110  for feeding aggregated XML feed data to clients  205 . 
     Clients  205  and servers  215  and  220  may connect to network  225  via wired, wireless, and/or optical connections. While servers  215  and  220  are shown as separate entities, it may be possible for one of servers  215  or  220  to perform one or more of the functions of the other one of servers  215  or  220 . For example, it may be possible that servers  215  and  220  are implemented as a single server. It may also be possible for a single one of servers  215  and  220  to be implemented as two or more separate (and possibly distributed) devices. 
     Network  225  may include one or more networks of any type, including a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network, such as the Public Switched Telephone Network (PSTN) or a Public Land Mobile Network (PLMN), an intranet, the Internet, a memory device, or a combination of networks. The PLMN(s) may further include a packet-switched sub-network, such as, for example, General Packet Radio Service (GPRS), Cellular Digital Packet Data (CDPD), or Mobile IP sub-network. 
     Exemplary Client/Server Architecture 
       FIG. 3  is an exemplary diagram of a client or server entity (hereinafter called “client/server entity”), which may correspond to one or more of clients  205  and/or servers  215  or  220 , according to an implementation consistent with the principles of the invention. The client/server entity may include a bus  310 , a processor  320 , a main memory  330 , a read only memory (ROM)  340 , a storage device  350 , an input device  360 , an output device  370 , and a communication interface  380 . Bus  310  may include a path that permits communication among the elements of the client/server entity. 
     Processor  320  may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory  330  may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor  320 . ROM  340  may include a ROM device or another type of static storage device that may store static information and instructions for use by processor  320 . Storage device  350  may include a magnetic and/or optical recording medium and its corresponding drive. 
     Input device  360  may include a mechanism that permits an operator to input information to the client/server entity, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. Output device  370  may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface  380  may include any transceiver-like mechanism that enables the client/server entity to communicate with other devices and/or systems. For example, communication interface  380  may include mechanisms for communicating with another device or system via a network, such as network  225 . 
     The client/server entity, consistent with the principles of the invention, may perform certain operations or processes, as will be described in detail below. The client/server entity may perform these operations in response to processor  320  executing software instructions contained in a computer-readable medium, such as memory  330 . A computer-readable medium may be defined as a physical or logical memory device and/or carrier wave. 
     The software instructions may be read into memory  330  from another computer-readable medium, such as data storage device  350 , or from another device via communication interface  380 . The software instructions contained in memory  330  may cause processor  320  to perform operations or processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the invention. Thus, implementations consistent with principles of the invention are not limited to any specific combination of hardware circuitry and software. 
     Exemplary XML Aggregator Secure Feed Process 
       FIGS. 4A and 4B  are a flowchart of an exemplary process for receiving a secure XML feed at an XML feed aggregator  100  consistent with principles of the invention. The process exemplified by  FIGS. 4A and 4B  may be performed by an XML feed aggregator  100  at a client  205  or server  220 . 
     The exemplary process may begin with XML feed aggregator  100  sending a poll  120  of the XML feed to XML feed provider  110  (block  400 ). In one implementation, an XML feed aggregator  100  at client  205  may send a poll  120  to an XML feed provider  110  at server  220 . In another implementation, an XML feed aggregator  100  at client  205  may send a poll to an XML feed provider  110  at server  215 . In a further implementation, an XML feed aggregator  100  at server  220  may send a poll  120  to an XML feed provider  110  at server  215 . In response to the poll, XML feed aggregator  100  may receive XML feed data  130  back from XML feed provider  110  (block  405 ). The XML feed data  130  may include un-secure content  134  and a link  138  to secure content. XML feed aggregator  100  may present the un-secure content of the XML feed data, and an image element associated with secure content, to a user (block  410 ). For example, as illustrated in  FIG. 5 , XML content may be presented to a user in a browser  500 , or other software application. The XML content may be presented as multiple XML feed entries  510 , each of which includes un-secure content  520  and a corresponding image element  530 . Un-secure content  520  may include, for example, a snippet (e.g., a portion) of data. Each image element  530  may indicate that secure, sensitive or private XML content has not been presented, but is available for access by the user if the user can authenticate. In some implementations, image element  530  may include a snippet of the secure content, plain text rendered as an image, a normal image (e.g., a graph), etc. Image element  530  may also include any type of data that serves to indicate that secure, sensitive or private XML content has not been presented, but is available for access by the user if the user can authenticate. 
     XML feed aggregator  100  may determine if the user has selected the secure content (block  415 ). For example, as shown in  FIG. 5 , a user may select  540  (e.g., “click” on with a mouse) an image element  530  that corresponds to the secure content that the user desires to access. If the user has selected secure content, a link associated with the secure content may be extracted from the XML feed data (block  420 ). The link may further be associated with the XML feed provider  110  that may provide the secure content, or with another entity or network location where the secure content is stored. The link may include, for example, a URL associated with the network location at which the secure content is stored. XML aggregator  100  may send a secure content request to the extracted link (block  425 ). In response to the secure content request, XML feed aggregator  100  may receive a user authentication request (block  430 ). XML feed provider  110 , or an entity associated with the extracted link, may send the user authentication request to XML aggregator  100  via network  225  in response to receipt of the secure content request. In response to receipt of the user authentication request, XML feed aggregator  100  may present a user authentication window  610  to the user, as illustrated in  FIG. 6 . The user authentication window  610  may request user authentication data from the user, such as, for example, the user&#39;s user name and password. 
     XML feed aggregator  100  may then send the user authentication data (block  435 ). XML feed aggregator  100  may send the user authentication data to XML feed provider  110 , or an entity associated with the extracted link, via network  225 . XML feed aggregator  100  may then receive a secure content download (block  440 ). The secure content may be received from XML feed provider  110 , or from an entity associated with the extracted link. XML feed aggregator  100  may present the secure content to a user (block  445 ). As illustrated in  FIG. 7 , the received secure content  700  may be displayed to the user along with its corresponding un-secure content  520 - 2 . Therefore, consistent with aspects of the invention described above, XML feed aggregator  100  does not “see” the secure content (e.g., the secure content is not provided to XML feed aggregator  100 ) until user authentication data is first supplied to XML feed provider  110 . 
     Exemplary XML Feed Provider Process 
       FIG. 8  is a flowchart of an exemplary process for feed authentication at XML feed provider  110  and for providing secure content based on the authentication. The process exemplified by  FIG. 8  may be performed by XML feed provider  110  at server  215 , by an XML feed provider  110  at server  220 , or in conjunction with another entity separate from servers  215  or  220 . 
     The exemplary process may begin with XML feed provider  110  receiving a poll  120  of the XML feed from XML feed aggregator  100  (block  800 ). XML feed provider  110  at server  215  or at server  220  may receive the poll  120 . In response to the poll, XML feed provider  110  may send an XML feed  120  containing un-secure content  134  and also containing a link  138  referencing secure content (block  810 ). XML feed provider  110  may send the XML feed  130  to XML feed aggregator  100  at server  220 , or to an XML feed aggregator  100  at a client  205 . 
     XML feed provider  110 , or an entity associated with the link  138 , may receive a secure content request  140  from XML aggregator  100  (block  820 ) and may then send a user authentication request  150  to XML aggregator  100  (block  830 ). In response to the user authentication request  150 , XML feed provider  110 , or the entity associated with the link  138 , may receive user authentication data  160  from XML feed aggregator  100  (block  840 ). XML feed provider  110 , or the entity associated with the link  138 , may, after ascertaining the validity of the user authentication data, upload secure content to XML feed aggregator  100  (block  850 ). 
     CONCLUSION 
     The foregoing description of implementations consistent with principles of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings, or may be acquired from practice of the invention. For example, while series of acts have been described with regard to  FIGS. 4A ,  4 B and  8 , the order of the acts may be modified in other implementations consistent with the principles of the invention. Further, non-dependent acts may be performed in parallel. Aspects of the invention have been described as being applicable to XML feeds. The principles of the invention as described herein may also be applied to the use of proprietary notification clients or email. 
     It will be apparent to one of ordinary skill in the art that aspects of the invention, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects consistent with the principles of the invention is not limiting of the invention. Thus, the operation and behavior of the aspects have been described without reference to the specific software code, it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein. 
     No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.