Patent Application
20070130221
The secure sharing of personal information among groups of individuals has long been a problem confronted by software developers. The challenge has been to enable an individual to publish information such that only specific individuals can access specific parts of the information. To some extent client-server software has enabled limited solutions to this challenge. One example is Microsoft's OUTLOOK personal information manager (PIM) client software combined with Microsoft's EXCHANGE SERVER software. This combination has enabled millions of individuals to share their information within workgroups, most commonly in a corporate or workplace environment.
The needs of users, however, are not limited to the workgroup or company setting. Frequently, users wish to share collections of personal information with a broader audience outside their workplace or organization. Examples include the sharing of a task list, a calendar of events, or a group of contacts (i.e. an address book). If a user wishes to share a calendar (e.g., upcoming football practices) with an audience outside his or her organization, the user must rely on technologies other than classic client-server software, technologies such as the Internet to allow access by other users.
Some solutions have been created which partially solve this problem. For example, calendar programs exist which can upload (publish) and download (subscribe to) calendars from servers attached to a network such as the Internet. These programs may use an Internet publishing standard such as Web-based Distributed Authoring and Versioning (WebDAV) to control publishing a calendar. Such programs, however, may not provide the ability to secure and filter the information available to others via the Internet.
Existing calendar solutions publish calendars without desirable restrictions. An entire calendar must typically be published, and calendars are frequently protected using a simple password protection scheme. Although somewhat secure, having a single password for a calendar makes it difficult to select who can and can't view the calendar on a person-by-person basis. For example, if three users are provided access to a published calendar by sharing the password with each of them, and one of the three subsequently has his access revoked, the publisher of the calendar must change the password and alert only the two remaining users of the change. Also, the password could be passed to others allowing them access to the information. Having a single password also makes it difficult to track who is accessing a calendar, and which person may have leaked the password to others. The single password may also be sent via insecure email and be subject to the prying eyes of others.
Furthermore, when publishing events or task items, the entire collection is published. This can be cumbersome for both the publisher and the users of the collection. Even though a few months or weeks of information may be relevant, the entire collection must be published each time there is a change. As an example, for a particularly large calendar stretching over a period of years, this may unnecessarily lengthen the amount of time to upload or download the calendar. In addition, the large calendar may take up too much memory and/or disk space on a server. Moreover, publishers may wish to limit the time period of calendar events published so that tentative future events remain unpublished.
There is a need in the art for the ability to publish a calendar to a server, such that the information published can be filtered, the access granted can be restricted on a user-by-user basis, and the granularity of data viewable by a user can be controlled. For example, a user may want to only give free/busy information to one person, while allowing another person to see the text of each appointment.
One or more embodiments provide a method for securely sharing a personal information collection (e.g., a calendar, a task list, or an address book) via a server. A publisher can specify individuals who will have access to the calendar (or other collection) and may also limit the period of time which can be viewed on a calendar by invited users.
Additional embodiments provide a method for receiving and sharing a personal information collection (e.g., a calendar or task list) on a server. The server receives the personal information collection, along with an indication of an audience authorized to view the collection. The server then requires that users requesting to view the collection be authenticated prior to allowing access.
The foregoing brief summary of the invention, as well as the following detailed description, is better understood when read in conjunction with the accompanying drawings, which are included by way of example, and not by way of limitation with regard to the claimed invention. In the accompanying drawings, the same or similar elements are labeled with the same reference numbers.
Information contained in PIM software 120 may be published using a “rolling window” of time in which information is published or withdrawn from view, ensuring that subscribers to the information do not view irrelevant or tentative information. Furthermore, the information can be secured on a user-by-user basis over a network such as the Internet in order to ensure that unauthorized viewers cannot access the information.
Generally, program modules may include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, set-top boxes, and so forth. Embodiments may also be practiced in distributed computing environments where tasks are performed by other computing devices 118 that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
Embodiments, for example, may be implemented as a computer process or method (e.g., in hardware or in software), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoded with a computer program of instructions for executing a process on computing device 100. The computer program product may also be a propagated signal on a carrier readable by a computing system and subsequently stored on a computer readable medium on computing device 100.
With reference to
Although the basic computing device configuration is contained within dashed-line box 108, computing device 100 may include additional features and functionality. For example, computing device 100 may include additional data storage components, including both removable storage 109 (e.g., floppy disks, memory cards, compact disc (CD) ROMs, digital video discs (DVDs), external hard drives, universal serial bus (USB) keys, etc.) and non-removable storage 110 (e.g., magnetic hard drives).
Computer storage media may include media implemented in any method or technology for storage of information, including computer readable instructions, data structures, program modules, or other data. Memory 104, removable storage 109, and non-removable storage 110 are all examples of computer storage media. Further examples of such media include RAM, ROM, electrically-erasable programmable ROM (EEPROM), flash memory, CD-ROM, DVD, cassettes, magnetic tape, magnetic disks, and so forth. Any such computer storage media may be accessed by components which are a part of computing device 100, or which are external to computing device 100 and connected via a communications link (e.g., Bluetooth, USB, parallel, serial, infrared, etc.). Computing device 100 may also include input devices 112, such as keyboards, mice, pens, microphone, touchpad, touch-display, etc. Output devices 114 may include displays, speakers, printers, and so forth. Additional forms of storage, input, and output devices may be utilized.
Computing device 100 may also include one or more communication connections 116 which allow the computing device to communicate with other computing devices 118, such as over a network (e.g., a local area network (LAN), the Internet, etc.). Communication media, in the form of computer readable instructions, data structures, program modules, or other data in a modulated data signal, may be shared with and by device 100 via communication connection 116. Modulated data signal may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the. signal, and may include a modulated carrier wave or other transport mechanism. Communication connection 116 may be comprised of hardware and/or software enabling either a wired (e.g., Ethernet, USB, Token Ring, modem, etc.) or wireless (e.g., WiFi, WiMax, cellular, acoustic, infrared, radio frequency (RF), etc.) communication conduit with other devices 118.
Calendar 210 may be sent in a standard format such as the Internet Engineering Task Force's iCalendar standard. Software on computer 201 may store information utilizing the same standard format as used for publication, or store the information in a different standard or proprietary format that is converted to a standard for publication. In addition to sending calendar event information, software on computer 201 may also send access and control information, describing who can and cannot access published calendar 211. Such information may be sent in a standard format (e.g., access & control (ACL)), or in a proprietary format. The access information sent may include a collection of email addresses and/or user names of individuals who are permitted to access published calendar 211.
Users 206a, 206b, and 206c each wish to access published calendar 211. Each attempts to access the calendar via a network-connected computer. Since publisher 202 opted to limit access to specific individuals, each user will have to establish his or her identity before the information can be accessed. In establishing each user's identity, server 203 and/or clients 206 may take advantage of authentication service 207, which may work locally on server 203, or remotely over a network 204 such as the Internet. An authentication service 207, such as MICROSOFT'S PASSPORT NETWORK, can authenticate and establish an identity for each user 206.
When user 206 attempts to access calendar 211 on server 203, he or she may be challenged to authenticate his or her identity, and subsequently be provided credentials establishing identity and allowing access to the information. Alternative authentication schemes need not require the services of remote authentication service 207. Including a simple login and password setup for each user on server 203 can accomplish the same goal. Here, users 206a and 206b have successfully been authenticated, and subsequently have accessed calendar 211. User 206c has not been authenticated and cannot access the information. Alternatively, user 206c may be authenticated (have his identity established) but not be authorized to access calendar 211. Should publisher 202 ever decide to exclude user 206b, she need only modify access restrictions for that particular user rather than change a single password for all users, and informing the remaining users of the new password.
Server 203 may be set up as a server uniquely providing secured sharing services for the PIM software 120 running on computer 201. Alternatively, server 203 may be a generic web server programmed to share information and provide secured access to the information. In utilizing the services of server 203, a publisher of information 202 may first need to register, pay for the services, and/or pay to upgrade a service level.
For computer 201, once sharing is triggered, network connectivity is checked at step 302. If at decision 303, there is no network connection to enable publishing, then at step 304, an appropriate error message is displayed. If a network connection is present, then at step 305, PIM software 120 is checked to see if it is configured for publishing (e.g., with the server information, etc.). If the software is so configured, then at step 306, an authentication dialog is optionally displayed for the publisher to verify his or her identity. Once authenticated, at decision 307, the steps can proceed, otherwise the publisher will have to re-authenticate, or cancel the operation. If the PIM software 120 is not configured to utilize publishing, then the publisher is provided an opportunity to register and/or pay to utilize a publishing service at step 308. At step 309, the new user receives their sign in information, and control proceeds.
Once authenticated, the publisher's registration is checked at decision 310 to see if she has already signed up for the specific sharing service required (e.g. calendar sharing, if it is provisioned separately from the publishing service generally). If not at step 311, the user can register for sharing, and at step 312, a sharing dialog can be displayed where a user can configure options for sharing the particular collection selected.
Dialog 401 provides publisher 202 with the ability to configure publication options for a calendar named Football Practices 402. The published version of the calendar will not include all events, but instead will include a limited time range of events, one that varies based on the current date. Input 403 permits the selection of an amount of time prior and following the current date to be displayed on the published calendar. In the case of a task list, publication of the collection item (a task versus an event) may be similarly filtered using the item's due date. Here, events falling within the range of 2 weeks prior to the current date and 3 weeks after the current date will be published.
Input 404 allows publisher 202 to select how much information about each event will be included on the published calendar. At a minimum, availability information is provided (e.g., whether a particular time period has an event), while the other end of the spectrum provides all details about events. As an example, “Full Details” may include all information about an event including whatever description has been entered. “Partial Details” may only include date, time, title, and location, without any additional information. Publisher 202 may also filter for showing only those events that occur during previously determined work hours. Calendar permissions can be controlled using input 405, to permit only certain users, or to allow all users. And uploading can be selected for automatic or manual using input 406. Input 409 can allow the details of events marked “private” to be published for others to access. Input 410 may allow the PIM software to honor upload limits of server 203 in order to prevent excessive use of bandwidth and/or memory. Once the appropriate options are configured, a user may publish the calendar immediately by clicking Publish button 407, or exit without publishing by clicking Cancel button 408.
Once options for calendar publication have been set, and a publisher has selected to restrict access to individual users, publisher 202 may be presented with a dialog (not shown) for inviting users to access his calendar. Such a dialog may also allow for each invited user to be restricted as to a level of access to the calendar. Some users may be able to access the full details of events, whereas others may simply be able to access whether or not an event occurs at a particular time (e.g., free/busy information). A publisher may be provided a template email into which she can insert contacts from her address book, or simply email addresses of those to be authorized to view the calendar. These individuals may then be sent an email with a link to the calendar. When clicking the link, these invited users may need to first be authenticated by server 203, or authentication service 207. Subsequent to the initial set of invitations, publisher 202 may modify the access settings for the calendar, inviting additional users, and revoking access for others.
If either of these checks is true, then at step 604, a publishable version of the collection will be created. The publishable version may conform to a particular standard (e.g., a calendar to the iCalendar specification), and also may honor any filters put in place by the user (e.g., a rolling time window, or business hour events only). At step 605, the just-generated publishable version is compared to the publishable version previously published. This comparison may involve an event by event analysis and/or may involve the comparison of hash values (e.g. CRC or MD5) to determine if the two files are the same. If, at decision 606, the two publishable versions are the same (e.g., no events within the rolling window have been changed, added, or removed, and therefore the files are identical), then at step 607, the publishable version of the collection will not be uploaded to server 203. If the publishable versions are different (e.g., events within the rolling window have changed), then at step 608, the newly generated publishable version of the personal information collection will be uploaded. At this point, users who subscribe to the calendar may receive notification of the change, or automatically receive the updated information.
While methods and systems embodying the present invention are shown by way of example, it will be understood that the invention is not limited to these embodiments. The methods and systems described are merely examples of the invention, the limits of which are set forth in the claims which follow. Those skilled in the art may make modifications, particularly in light of the foregoing teachings.
