Various embodiments of the present invention are directed to providing a user the ability to self-declare one or more permission attributes about the user that form the basis for the filtering (e.g., the dynamic filtering) of current and/or future content. In this manner, access to the content may thus be governed by the self-declared permission attributes (in one example (which example is intended to be illustrative and not restrictive), the present invention may operate within a secure, tracked content delivery infrastructure).
For the purposes of describing and claiming the present invention the term “self-declared” is intended to refer to an indication or selection associated with a given entity that is made by the given entity itself.
Further, for the purposes of describing and claiming the present invention the term “value” (e.g., as used in “classification value” or “permission attribute value”) is intended to refer to a numeric indicator (e.g., a distinct number, a range of numbers) or an alphanumeric indicator (e.g., a text label such as “private”, “public”, “yes”, “no”).
Security systems typically provide a way of filtering information based on criteria that are defined by an administrator. While such a typical security system may prevent a user from gaining access to protected system content if the user is not explicitly permissioned to do so, various embodiments of the present invention provide the ability to reveal certain content only to users with certain attributes, even if, for example, the system administrator is unaware of the user's identity or affiliation and the user is unaware of the nature of the content.
The filtering of the present invention may thus dynamically allow the same content to be accessed or not accessed by a particular user, based on self-declared permission attribute(s), in each situation. For example, the ability to self-declare the permission attribute(s) may help reduce the administrative overhead associated with granting or withdrawing permissions (e.g., depending on the business process) and enhance compliance with laws and policies regulating the users.
Of note, a security system working properly typically prevents access to information such that a user should only gain access to information that he or she should not have only in the event of mistakes by the system administrator. Unauthorized access otherwise should not occur while the system is operational.
In this regard, introducing the ability of a user to self-declare permission attribute(s) may increase the risk of abuse or violation of policies. Various embodiments of the present invention therefore provide the ability to track access to information. This audit information can be reviewed, for example, in the form of a report or sophisticated search criteria and can return a list of possible violations of regulations (e.g., a compliance officer can use the findings to investigate possible violations).
One embodiment of the present invention relates to a computer implemented method of controlling access to at least one document, comprising: receiving for storage from a first user at least one document; receiving from the first user at least one classification associated with the stored document, wherein the classification has a value selected from at least a first classification value and a second classification value; receiving from a second user at least one permission attribute associated with the second user, wherein the permission attribute associated with the second user is self-declared and wherein the permission attribute has a value selected from at least a first permission attribute value and a second permission attribute value; and permitting the second user to access the stored document if the classification value of the stored document matches the permission attribute value declared by the second user.
One example business reason for utilizing the present invention may stem from concerns within the syndicated loan market. In such a syndicated loan market, loans are marketed to investors (including, without limitation, banks, debt funds, hedge funds). Many of the investors are institutional investors that invest in both the public markets (e.g., bonds, equity) and in the private loan market. Since disclosure related to certain loans often includes material non-public information (i.e., “private” information such as financial projections), these institutional investors have the potential to be conflicted with regard to insider trading regulations (e.g., regulations promulgated by the SEC). As such, users within these firms may require the ability to indicate their status on a particular loan based on: a) whether they are or may trade in the stocks/bonds of that borrowing entity (e.g., on the “public” side); and/or b) have procedure to prevent trading securities of the borrower or have walls/controls that allow them to trade in securities of the borrower while also investing in the loan market (e.g., on the “private” side). Based on their position for any given borrower, they should only see appropriate disclosure materials. Even accidental exposure to “private” information for a “public” investor can be problematic (syndicating agents are typically not aware of each investor's position for any given borrower and therefore typically have no clear way to permission content to them).
Similarly, in another example (which example is intended to be illustrative and not restrictive), classifications may be assigned so as to not cause parties involved in pre-merger due diligence or formation of joint ventures to violate antitrust regulations. Users such as professional advisors, executive management or directors could be granted broader access to counterparty information than users from within operating units (e.g., sales, regional managers, etc.), so that pricing and other information can be filtered, without knowing in advance the name, affiliation or security level of all users that could be invited to access content on the system for purposes of the transaction.
Similarly, in yet another example (which example is intended to be illustrative and not restrictive), classifications may be assigned so as to preserve attorney-client privilege with respect to content. Only users that identify themselves in a manner consistent with the preservation of privilege (e.g. attorneys rendering advice or responding to requests for legal advice and persons within client organizations authorized to request and receive legal advice) would be granted access to the content associated with such classifications.
Among those benefits and improvements that have been disclosed, other objects and advantages of this invention will become apparent from the following description taken in conjunction with the accompanying figures. The figures constitute a part of this specification and include illustrative embodiments of the present invention and illustrate various objects and features thereof.
Detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely illustrative of the invention that may be embodied in various forms. In addition, each of the examples given in connection with the various embodiments of the invention is intended to be illustrative, and not restrictive. Further, the figures are not necessarily to scale, some features may be exaggerated to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
Referring now to
More particularly,
Of course, after content is uploaded to the enterprise information system, the uploader, an administrator or a content manager may change the visibility setting for the content (defined by the classification value). Thus, in this example, the visibility setting may be changed from “Public” to “Private” or visa versa.
Referring now to
Further, as seen in
Of course, users may be given the opportunity to change the self-declared permission attributes. That is, the initially self-declared permission attribute(s) could applied to all visits to the system or portions thereof until the user explicitly changes the user's attribute(s) within the user profile section of the enterprise information system or elsewhere (e.g., through a user interface). In this regard,
Referring now to
More particularly, in one example (which example is intended to be illustrative and not restrictive), an audit entry may comprise the user's name and ID, date and time of the access, information related to the content and other data. An additional audit entry may made each and every time a user accesses any content in the system (anywhere in the system or in one or more specific portions of the system). Also recorded may be any changes to a user's self-declared permission attributes(s).
All audit records related to the content access, the content classification and/or the user's self-declared permission attribute(s) may be made available to authorized users and administrators through reports. The audit record may be used to provide a compliance officer of a company or regulatory entities with the ability to track compliance and detect violations of the regulations or company policies and take corrective action.
In another example (which example is intended to be illustrative and not restrictive), auditing policies can be embodied as follows: 1) in a definition in a user interface and stored in database tables and interpreted (or compiled) during runtime; 2) in a definition in configuration fields that are interpreted by business logic; and/or 3) in business logic that is incorporated into an existing system.
Referring now to
In one example (which example is intended to be illustrative and not restrictive), an alert related to content classified as “public” will go to appropriate users who have self-declared permission attributes of “public” or “private”.
In another example (which example is intended to be illustrative and not restrictive), an alert related to content classified as “private” will go to appropriate users who have self-declared permission attributes of “public” or “private” (wherein “public” users are responsible for actually accessing the content or not).
In another example (which example is intended to be illustrative and not restrictive), an alert related to content classified as “private” will go to appropriate users who have self-declared a permission attribute of only “private” (wherein self-declared “public” users are not notified by the alert).
As described above, one embodiment of the present invention enables administrators and content managers to associate classifications and allowable classification values with the content of an enterprise information system. These classifications may already be included in the enterprise information system or may be specifically designed by its system administrator to represent classifications of the content. The classifications are typically not part of the content but may describe and represent the user characteristics, security clearance levels and/or metadata associated with access to the content.
In one example (which example is intended to be illustrative and not restrictive), the present invention may provide a user of an enterprise information system with the ability to dynamically select an existing or create a new information filter for current and/or future content managed by the enterprise information system.
In another example (which example is intended to be illustrative and not restrictive), a user may be required to select an existing or create a new permission attribute when he or she accesses the system the first time or after new classifications/permission attributes have been added. This may be done as soon as the user passes appropriate user credentials to the enterprise information system but before the user gains access to the functions of the enterprise information system (see, e.g.,
In another example (which example is intended to be illustrative and not restrictive), permission attribute(s) may be selected that are known to the user, notwithstanding that the user may not know or anticipate the nature, purpose or substance of the content on which such permission attributes(s) will act as a filter.
In another example (which example is intended to be illustrative and not restrictive), filtering may act on any single attribute or combination of multiple attributes, such that a plurality of users with the same permission attribute(s) may not have access to the same content, to the extent access is filtered by other attribute(s) or combinations of attribute(s).
In another example (which example is intended to be illustrative and not restrictive), the present invention may classify information not only based upon content but upon a location of a document within the system, a publication source, a comment, a reply, and/or association with other users (among other possibilities).
In another example (which example is intended to be illustrative and not restrictive), the visibility of certain information (e.g., represented by hyperlinks to stored information) may be implemented through various columns in database tables.
In another example (which example is intended to be illustrative and not restrictive), two (or more) aliases or user names per user could be defined. One alias could apply automatically one or more attributes for purposes of filtering access to content; the other aliases could apply to other attribute(s) for filtering access to content.
In another example (which example is intended to be illustrative and not restrictive), the system or system administrator can turn on or off each user's ability to self-declare permission attribute(s).
In another example (which example is intended to be illustrative and not restrictive), a limited or essentially unlimited number of classifications/classification values may be defined and linked to content, independent of modifications to the core system for storing and/or distributing content. Depending on the implementation strategy, the extensions can be made while the system is operating or before the system is restarted (of course, any desired number of self-declared permission attributes/permission attribute values may also be utilized).
For a limited number of classifications (e.g. 1 to 10), the system may add additional columns to the content tables in the database to be used only when an additional classification information is added. The business logic could manage the classifications and could expand the queries as new classifications are added. Under this approach the query overhead may be minimized and the overall system performance may not be significantly impacted.
For an essentially unlimited number of classifications to be supported, the classifications could be placed in separate database tables and linked with a 1-n relationship to the content tables. Filtering could be accomplished using either an additional query per access to content or a table joined between the table that contains the content and the table that contains the classifications and their allowable values.
The allowable values per classification may be defined in multiple ways including, but not limited to, the following approaches:
The business logic and user interface may be constructed so that the classifications are considered when content is retrieved and/or updated.
The system programmer, system administrator, and/or user could create filters depending on the required flexibility in multiple ways including, but not limited to, the following approaches:
Referring now to
More particularly, as seen in the example of
Referring now to
Referring now to the example of
Referring now to
Referring now to
Referring now to
Referring now to
Finally, reference will now be made to a number of examples directed to permission attributes and permission attribute values (of course, these examples are intended to be illustrative, and not restrictive).
More particularly, in one example (as discussed above) a permission attribute may refer to a user's public/private status relative to certain information. Associated permission attribute values may be, for example, “private” and “public”. In another example, associated permission attribute values may be “yes” and “no” (indicating a private status or a public status). In another example, associated permission attribute values may be “1” and “0” (indicating a private status or a public status).
In another example, a permission attribute may refer to a user's country of residence. Associated permission attribute values may be, for example, “USA” and “Other”. In another example, associated permission attribute values may be “yes” and “no” (indicating a USA residence status or another residence status). In another example, associated permission attribute values may be “1” and “0” (indicating a USA residence status or another residence status).
In another example, a permission attribute may refer to a user's security level. Associated permission attribute values may be, for example, “High” and “Low”. In another example, associated permission attribute values may be “yes” and “no” (indicating a high security level or a low security level). In another example, associated permission attribute values may be “1” and “0” (indicating a high security level or a low security level). In another example, associated permission attribute values may be in a numeric range (indicating a security level within a range).
In another example, a permission attribute may refer to a user's age. Associated permission attribute values may be, for example, “at least 18 years old” and “below 18 years old”. In another example, associated permission attribute values may be “yes” and “no” (indicating at least 18 years old or below 18 years old). In another example, associated permission attribute values may be “1” and “0 (indicating at least 18 years old or below 18 years old). In another example, associated permission attribute values may be a user's age.
Of course, any number of permission attributes may be combined in controlling access to information. For example (which example is intended to be illustrative, and not restrictive), a first user who is a “private” user and is a “USA resident” may be granted access to a first set of information; a second user who is a “public” user and is a “USA resident” may be granted access to a second set of information; a third user who is a “private” user and is “not a USA resident” may be granted access to a third set of information; and a fourth user who is a “public” user and is “not a USA resident” may be granted access to a fourth set of information (in this example, the first through fourth sets of information may be distinct from one another or there may be overlap (partial or total) between information in one or more of the sets of information).
In another example, the steps are carried out in the order recited. In another example, the first permission attribute value and the third permission attribute value are the same and the second permission attribute value and the fourth permission attribute value are the same.
While a number of embodiments of the present invention have been described, it is understood that these embodiments are illustrative only, and not restrictive, and that many modifications may become apparent to those of ordinary skill in the art. For example, an implementation of the present invention may separate the filter logic from the logic related to the security system (of course, the security system may be extended to enforce also the filter criteria). Further, the content filter may be designed and implemented to facilitate compliance with federal and/or state regulations and/or with corporate policies regarding access to information (e.g., access to “private” information). Further still, under various embodiments of the present invention certain users (e.g., syndicating agent, administrative agent, sales desk) do not need to be responsible for knowing and identifying what information is private. Rather, an issuer may be responsible for this (e.g., by classifying uploaded documents appropriately). Likewise, under various embodiments of the present invention certain users (e.g., syndicating agent, administrative agent, sales desk) do not need to be responsible for knowing and identifying a given investor's “status” (e.g., private or public) relative to a given issuer. Rather, each investor may be responsible for this (e.g., by self-declaring one or more permission attributes). Moreover, under various embodiments of the present invention certain users (e.g., loan investors) may be provided a mechanism for identifying “private” information in order to minimize the potential for unintentional/inappropriate exposure (the present invention may provide for this to be handled in the market by a consistent industry approach). Further still, the present invention may be used to apply other classifications and filters that are built in essentially the same way as the “visibility” classification, e.g., by adding additional columns to content tables and extending business logic and database queries to reflect their meaning to the business process (under this implementation strategy the system performance may be optimized since the system can perform very efficient filtering at the database layer). Further still, the self-declared permission attributes of the present invention may be applied to all content managed by an enterprise information system or to a subset of the content managed by an enterprise information system. (e.g., on a client by client basis or on a deal by deal basis). Further still, access to specific content may be filtered by hiding certain content (e.g., providing a given user a list of hyperlinks to content which may be accessed by that user, based upon the content classification and the user's self-declared permission attribute(s), and not including in the list of hyperlinks any excluded content) or by prohibiting access to certain content (e.g., providing a given user a list of hyperlinks to content which may or may not be accessed by that user, based upon the content classification and the user's self-declared permission attribute(s), and prohibiting assess to excluded content if the user clicks an excluded hyperlink). Further still, the various steps may be performed in any desired order, one or more steps may be deleted and/or one or more steps may be added.
This application claims the benefit of U.S. Provisional Application Ser. No. 60/667,888, filed Apr. 1, 2005, which is incorporated herein by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
5537618 | Boulton et al. | Jul 1996 | A |
5630159 | Zancho | May 1997 | A |
5694596 | Campbell | Dec 1997 | A |
5721827 | Logan et al. | Feb 1998 | A |
5771355 | Kuzma | Jun 1998 | A |
5781901 | Kuzma | Jul 1998 | A |
5790790 | Smith et al. | Aug 1998 | A |
5815665 | Teper et al. | Sep 1998 | A |
5898780 | Liu et al. | Apr 1999 | A |
5903723 | Beck et al. | May 1999 | A |
5923756 | Shambroom | Jul 1999 | A |
5937405 | Campbell | Aug 1999 | A |
5961590 | Mendez et al. | Oct 1999 | A |
6029146 | Hawkins et al. | Feb 2000 | A |
6088722 | Herz et al. | Jul 2000 | A |
6092114 | Shaffer et al. | Jul 2000 | A |
6112181 | Shear et al. | Aug 2000 | A |
6148342 | Ho | Nov 2000 | A |
6192407 | Smith et al. | Feb 2001 | B1 |
6223177 | Tatham et al. | Apr 2001 | B1 |
6233608 | Laursen et al. | May 2001 | B1 |
6253326 | Lincke et al. | Jun 2001 | B1 |
6266692 | Greenstein | Jul 2001 | B1 |
6370575 | Dougherty et al. | Apr 2002 | B1 |
6385644 | Devine et al. | May 2002 | B1 |
6385655 | Smith et al. | May 2002 | B1 |
6397261 | Eldridge et al. | May 2002 | B1 |
6421678 | Smiga et al. | Jul 2002 | B2 |
6430601 | Eldridge et al. | Aug 2002 | B1 |
6442571 | Haff et al. | Aug 2002 | B1 |
6453348 | Barnier et al. | Sep 2002 | B1 |
6493760 | Pendlebury et al. | Dec 2002 | B1 |
6515988 | Eldridge et al. | Feb 2003 | B1 |
6529956 | Smith et al. | Mar 2003 | B1 |
6591291 | Gabber et al. | Jul 2003 | B1 |
6678698 | Fredell et al. | Jan 2004 | B2 |
6718367 | Ayyadurai | Apr 2004 | B1 |
6738981 | Tonnby et al. | May 2004 | B1 |
6816906 | Icken et al. | Nov 2004 | B1 |
6898636 | Adams et al. | May 2005 | B1 |
6904449 | Quinones | Jun 2005 | B1 |
6941285 | Sarcanin | Sep 2005 | B2 |
7140035 | Karch | Nov 2006 | B1 |
7143175 | Adams et al. | Nov 2006 | B2 |
7146367 | Shutt | Dec 2006 | B2 |
7168094 | Fredell | Jan 2007 | B1 |
7225157 | Howard et al. | May 2007 | B2 |
7233992 | Muldoon et al. | Jun 2007 | B1 |
7302634 | Lucovsky et al. | Nov 2007 | B2 |
7580988 | Rudd | Aug 2009 | B2 |
7587504 | Adams et al. | Sep 2009 | B2 |
7814537 | Fredell | Oct 2010 | B2 |
7966388 | Pugaczewski et al. | Jun 2011 | B1 |
8751793 | Ginter et al. | Jun 2014 | B2 |
20010027477 | Nakamura et al. | Oct 2001 | A1 |
20010028364 | Fredell et al. | Oct 2001 | A1 |
20020095499 | Barnett et al. | Jul 2002 | A1 |
20020099837 | Oe et al. | Jul 2002 | A1 |
20020112240 | Bacso et al. | Aug 2002 | A1 |
20020123924 | Cruz | Sep 2002 | A1 |
20020138744 | Schleicher et al. | Sep 2002 | A1 |
20020156695 | Edwards | Oct 2002 | A1 |
20020162005 | Ueda et al. | Oct 2002 | A1 |
20020162027 | Itwaru | Oct 2002 | A1 |
20020184191 | Marpe et al. | Dec 2002 | A1 |
20030046313 | Leung et al. | Mar 2003 | A1 |
20030074580 | Knouse et al. | Apr 2003 | A1 |
20030097410 | Atkins et al. | May 2003 | A1 |
20030105734 | Hitchen et al. | Jun 2003 | A1 |
20030105764 | Kageyama et al. | Jun 2003 | A1 |
20030105978 | Byrne | Jun 2003 | A1 |
20030172296 | Gunter | Sep 2003 | A1 |
20030225763 | Guilak et al. | Dec 2003 | A1 |
20030225796 | Matsubara | Dec 2003 | A1 |
20030226105 | Waldau | Dec 2003 | A1 |
20030229900 | Reisman | Dec 2003 | A1 |
20040006594 | Boyer et al. | Jan 2004 | A1 |
20040034646 | Kimball et al. | Feb 2004 | A1 |
20040054790 | Himmel et al. | Mar 2004 | A1 |
20040103202 | Hildebrand et al. | May 2004 | A1 |
20040221118 | Slater et al. | Nov 2004 | A1 |
20040267762 | Tunning et al. | Dec 2004 | A1 |
20050060643 | Glass et al. | Mar 2005 | A1 |
20050091077 | Reynolds | Apr 2005 | A1 |
20050102534 | Wong | May 2005 | A1 |
20050114661 | Cheng et al. | May 2005 | A1 |
20050138110 | Redlich et al. | Jun 2005 | A1 |
20050193043 | Hoover | Sep 2005 | A1 |
20050231738 | Huff et al. | Oct 2005 | A1 |
20050240572 | Sung et al. | Oct 2005 | A1 |
20060031412 | Adams et al. | Feb 2006 | A1 |
20060047752 | Hornby | Mar 2006 | A1 |
20060048099 | Templin et al. | Mar 2006 | A1 |
20060075028 | Zager et al. | Apr 2006 | A1 |
20060136417 | Avinash et al. | Jun 2006 | A1 |
20070079137 | Tu | Apr 2007 | A1 |
20070088846 | Adams et al. | Apr 2007 | A1 |
20070118889 | Fredell | May 2007 | A1 |
20070185875 | Chang et al. | Aug 2007 | A1 |
20070266104 | Bolf et al. | Nov 2007 | A1 |
20080201299 | Lehikoinen et al. | Aug 2008 | A1 |
20090172795 | Ritari et al. | Jul 2009 | A1 |
20090204580 | Seamon et al. | Aug 2009 | A1 |
20100005520 | Abbot et al. | Jan 2010 | A1 |
20100138797 | Thorn | Jun 2010 | A1 |
20110029666 | Lopatecki et al. | Feb 2011 | A1 |
20110289574 | Hull et al. | Nov 2011 | A1 |
20130054514 | Barrett-Kahn | Feb 2013 | A1 |
20130318589 | Ford et al. | Nov 2013 | A1 |
20140047560 | Meyer et al. | Feb 2014 | A1 |
20140143831 | Fieweger | May 2014 | A1 |
20140189483 | Awan et al. | Jul 2014 | A1 |
20140189818 | Meyer | Jul 2014 | A1 |
20140245015 | Velamoor et al. | Aug 2014 | A1 |
20140304836 | Velamoor et al. | Oct 2014 | A1 |
Number | Date | Country |
---|---|---|
2002318802 | Oct 2002 | JP |
2011160855 | Dec 2011 | WO |
2013163625 | Oct 2013 | WO |
2014025809 | Feb 2014 | WO |
2014063030 | Apr 2014 | WO |
2014063030 | Sep 2014 | WO |
2014152025 | Sep 2014 | WO |
2014152025 | Nov 2014 | WO |
Entry |
---|
“Cimage Content Lifecycle Management”, available at: http://web.archive.org/web/20010205074400/www.cimage.com/products/e31index.html, retrieved on Sep. 23, 2001, 1 page. |
“Doculogic Press Release”, available at: www.archivesystems.com/pressroom/press—doculogic.asp, retrieved on Apr. 11, 2000, 2 pages. |
“DocuTouch Features”, available at : http://web.archive.org/web/20011218003617/www.docutouch.com/dt—productfeatures.html, retrived on Dec. 17, 2001, 2 pages. |
“FilesOnTheNet.com Product Specifications”, available at: http://webarchive.org/web/20000914181459/www.filesonthenet.com/FOTNProdSoecs.PDF, retrieved on Sep. 14, 2000, 4 pages. |
“Net Documents Overview”, available at: http://web.archive.org/web/20010822083155/www. netdocuments.com/main.asp?l1=5&12=1&13=510, retrieved on Jul. 6, 2001, 1 page. |
Backer, Andreas et al., “DocMan: A Document Management System for Cooperation Support”, Proceedings of the Twenty-Ninth Hawaii International Conference on System Science, vol. 3, Jan. 3-6, 1996, pp. 82-91. |
Barker, Brian , “M&A Today, a Newsletter for the Professional Intermediary vol. 8, No. 9”, Sep. 1999, 4 pages. |
Braun, T. et al., “Virtual Private Network Architecture”, Apr. 1999, pp. 1-31. |
Chan, M. C. et al., “Customer Management and Control of Broadband VPN Services”, Integrated Network Management, 1997, 14 pages. |
Netscape Extranet Standards, “Overview of Extranet Standards: Extending the Networked Enterprise”, http://web.archive.org/web/19990218194752/http://sitesearch.netscape.com/products/whitepaper/extranetstds.html, 1999, 5 pages. |
PCT/US2013/038533, , “International Application Serial No. PCT/US2013/038533, International Search Report and Written Opinion mailed Aug. 23, 2013”, Interest Intralinks, Inc., 23 pages. |
Screen Shot of Page of IntraLinks Web Site; www.intralinks.com, 2004 |
PCT/US2014/026830, “International Application Serial No. PCT/US2014/026830, International Search Report and Written Opinion mailed Sep. 17, 2014”, Intralinks, Inc., 18 Pages. |
PCT/US2013/053835, International Application Serial No. PCT/US2013/053835, International Search Report and Written Opinion mailed Nov. 27, 2013, Intralinks, Inc., 13 Pages. |
PCT/US2013/065646, International Application Serial No. PCT/US2013/065646, International Search Report and Written Opinion mailed Feb. 10, 2014, Intralinks, Inc., 14 Pages. |
Number | Date | Country | |
---|---|---|---|
60667888 | Apr 2005 | US |