US20060136728A1  Method and apparatus for authentication of data streams with adaptively controlled losses  Google Patents
Method and apparatus for authentication of data streams with adaptively controlled losses Download PDFInfo
 Publication number
 US20060136728A1 US20060136728A1 US10/543,640 US54364005A US2006136728A1 US 20060136728 A1 US20060136728 A1 US 20060136728A1 US 54364005 A US54364005 A US 54364005A US 2006136728 A1 US2006136728 A1 US 2006136728A1
 Authority
 US
 United States
 Prior art keywords
 data stream
 blocks
 receiver
 values
 hash
 Prior art date
 Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
 Abandoned
Links
 230000000875 corresponding Effects 0.000 claims description 15
 238000004891 communication Methods 0.000 claims description 12
 238000000034 methods Methods 0.000 claims description 9
 230000004931 aggregating Effects 0.000 claims description 2
 238000004590 computer program Methods 0.000 claims 15
 239000010410 layers Substances 0.000 claims 5
 230000002401 inhibitory effect Effects 0.000 abstract 1
 238000007906 compression Methods 0.000 description 16
 238000010276 construction Methods 0.000 description 8
 230000001131 transforming Effects 0.000 description 8
 230000005540 biological transmission Effects 0.000 description 7
 238000010586 diagram Methods 0.000 description 7
 238000000844 transformation Methods 0.000 description 4
 230000003044 adaptive Effects 0.000 description 3
 230000006399 behavior Effects 0.000 description 3
 230000002457 bidirectional Effects 0.000 description 3
 230000003139 buffering Effects 0.000 description 3
 239000000463 material Substances 0.000 description 3
 230000004048 modification Effects 0.000 description 2
 238000006011 modification reaction Methods 0.000 description 2
 238000005457 optimization Methods 0.000 description 2
 XCCTYIAWTASOJWXVFCMESISAN Uridine5'Diphosphate Chemical compound data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0naXNvLTg4NTktMSc/Pgo8c3ZnIHZlcnNpb249JzEuMScgYmFzZVByb2ZpbGU9J2Z1bGwnCiAgICAgICAgICAgICAgeG1sbnM9J2h0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnJwogICAgICAgICAgICAgICAgICAgICAgeG1sbnM6cmRraXQ9J2h0dHA6Ly93d3cucmRraXQub3JnL3htbCcKICAgICAgICAgICAgICAgICAgICAgIHhtbG5zOnhsaW5rPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rJwogICAgICAgICAgICAgICAgICB4bWw6c3BhY2U9J3ByZXNlcnZlJwp3aWR0aD0nMzAwcHgnIGhlaWdodD0nMzAwcHgnIHZpZXdCb3g9JzAgMCAzMDAgMzAwJz4KPCEtLSBFTkQgT0YgSEVBREVSIC0tPgo8cmVjdCBzdHlsZT0nb3BhY2l0eToxLjA7ZmlsbDojRkZGRkZGO3N0cm9rZTpub25lJyB3aWR0aD0nMzAwJyBoZWlnaHQ9JzMwMCcgeD0nMCcgeT0nMCc+IDwvcmVjdD4KPHBhdGggY2xhc3M9J2JvbmQtMCcgZD0nTSAxODEuMzk0LDEyMC4yMTEgTCAxODcuNTI5LDExNS4zODEgTCAxODUuNTcsMTEzLjYxNCBaJyBzdHlsZT0nZmlsbDojM0I0MTQzO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoycHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MTsnIC8+CjxwYXRoIGNsYXNzPSdib25kLTAnIGQ9J00gMTg3LjUyOSwxMTUuMzgxIEwgMTg5Ljc0NiwxMDcuMDE2IEwgMTkzLjY2MywxMTAuNTUgWicgc3R5bGU9J2ZpbGw6I0U4NDIzNTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MnB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjE7JyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0wJyBkPSdNIDE4Ny41MjksMTE1LjM4MSBMIDE4NS41NywxMTMuNjE0IEwgMTg5Ljc0NiwxMDcuMDE2IFonIHN0eWxlPSdmaWxsOiNFODQyMzU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjJweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxOycgLz4KPHBhdGggY2xhc3M9J2JvbmQtMScgZD0nTSAxODEuMzk0LDEyMC4yMTEgTCAxNTUuMTY0LDExNy40MjknIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTI0JyBkPSdNIDE4MS4zOTQsMTIwLjIxMSBMIDE4Ni44NTMsMTQ2LjAxNycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMicgZD0nTSAxNTUuMTY0LDExNy40MjkgTCAxNTIuNzUsMTEwLjU5NSBMIDE1MC40NjUsMTExLjkxMiBaJyBzdHlsZT0nZmlsbDojM0I0MTQzO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoycHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MTsnIC8+CjxwYXRoIGNsYXNzPSdib25kLTInIGQ9J00gMTUyLjc1LDExMC41OTUgTCAxNDUuNzY1LDEwNi4zOTUgTCAxNTAuMzM2LDEwMy43NjIgWicgc3R5bGU9J2ZpbGw6I0U4NDIzNTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MnB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjE7JyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yJyBkPSdNIDE1Mi43NSwxMTAuNTk1IEwgMTUwLjQ2NSwxMTEuOTEyIEwgMTQ1Ljc2NSwxMDYuMzk1IFonIHN0eWxlPSdmaWxsOiNFODQyMzU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjJweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxOycgLz4KPHBhdGggY2xhc3M9J2JvbmQtMycgZD0nTSAxNTUuMTY0LDExNy40MjkgTCAxNDQuNDEyLDE0MS41MTUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTQnIGQ9J00gMTM5LjE0MiwxNDIuMDkxIEwgMTM5LjM2LDE0My4xMjMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTQnIGQ9J00gMTMzLjg3MiwxNDIuNjY2IEwgMTM0LjMwOCwxNDQuNzMxJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC00JyBkPSdNIDEyOC42MDEsMTQzLjI0MiBMIDEyOS4yNTYsMTQ2LjMzOScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNCcgZD0nTSAxMjMuMzMxLDE0My44MTggTCAxMjQuMjA0LDE0Ny45NDcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTQnIGQ9J00gMTE4LjA2MSwxNDQuMzkzIEwgMTE5LjE1MiwxNDkuNTU1JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNCcgZD0nTSAxNDQuNDEyLDE0MS41MTUgTCAxNTAuMzM0LDE0Ni44NTcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE0JyBkPSdNIDE1MC4zMzQsMTQ2Ljg1NyBMIDE1Ni4yNTYsMTUyLjE5OScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNScgZD0nTSAxMTguNjA2LDE0Ni45NzQgTCAxMTUuOTYsMTU1LjA5Mycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNScgZD0nTSAxMTUuOTYsMTU1LjA5MyBMIDExMy4zMTMsMTYzLjIxMicgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNicgZD0nTSAxMDEuNDQ1LDE3My45NTMgTCA5Ny40MTMzLDE3NC44MDYnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTYnIGQ9J00gOTcuNDEzMywxNzQuODA2IEwgOTMuMzgxMywxNzUuNjU5JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC03JyBkPSdNIDg2Ljk3MjMsMTg4LjYwNyBMIDg3LjYwNzcsMTkxLjYxMScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNycgZD0nTSA4Ny42MDc3LDE5MS42MTEgTCA4OC4yNDMyLDE5NC42MTUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTgnIGQ9J00gODUuMzA0OCwxNjcuOTc5IEwgODQuNjc1LDE2NS4wMDMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNGRjYwQjc7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTgnIGQ9J00gODQuNjc1LDE2NS4wMDMgTCA4NC4wNDUzLDE2Mi4wMjYnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTgnIGQ9J00gODAuMTQzNiwxNjkuMDcxIEwgNzkuNTEzOCwxNjYuMDk0JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC04JyBkPSdNIDc5LjUxMzgsMTY2LjA5NCBMIDc4Ljg4NDEsMTYzLjExNycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtOScgZD0nTSA3NS42MzkyLDE3OS40MTIgTCA3MS42MDcyLDE4MC4yNjUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNGRjYwQjc7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTknIGQ9J00gNzEuNjA3MiwxODAuMjY1IEwgNjcuNTc1MywxODEuMTE4JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMCcgZD0nTSA1MS44NTU5LDE3NS4yMjIgTCA1MC4wNjczLDE3My4yMzEnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTEwJyBkPSdNIDUwLjA2NzMsMTczLjIzMSBMIDQ4LjI3ODcsMTcxLjI0MScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTEnIGQ9J00gNDguOTM2OSwxNTYuMzg4IEwgNTEuMTI4MiwxNTQuNDE5JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMScgZD0nTSA1MS4xMjgyLDE1NC40MTkgTCA1My4zMTk0LDE1Mi40NDknIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTEyJyBkPSdNIDM0LjIyNTIsMTU1LjYwMyBMIDMyLjQzNjYsMTUzLjYxMicgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTInIGQ9J00gMzIuNDM2NiwxNTMuNjEyIEwgMzAuNjQ4MSwxNTEuNjIyJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMycgZD0nTSAzMS42NzY4LDE2OC4zNTIgTCAyOS40ODU1LDE3MC4zMjEnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNGRjYwQjc7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTEzJyBkPSdNIDI5LjQ4NTUsMTcwLjMyMSBMIDI3LjI5NDIsMTcyLjI5MScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTMnIGQ9J00gMzUuMjAyOSwxNzIuMjc2IEwgMzMuMDExNiwxNzQuMjQ1JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMycgZD0nTSAzMy4wMTE2LDE3NC4yNDUgTCAzMC44MjAzLDE3Ni4yMTQnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE1JyBkPSdNIDE3Mi4zOTMsMTU0LjM0NyBMIDE3OS42MjMsMTUwLjE4Micgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTUnIGQ9J00gMTc5LjYyMywxNTAuMTgyIEwgMTg2Ljg1MywxNDYuMDE3JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNicgZD0nTSAxOTEuNjQzLDE0OS4xMTggTCAxOTIuMzYsMTQ3LjUxMycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTYnIGQ9J00gMTk2LjQzMywxNTIuMjE5IEwgMTk3Ljg2NiwxNDkuMDA4JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojNDI4NEY0O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNicgZD0nTSAyMDEuMjIzLDE1NS4zMiBMIDIwMy4zNzMsMTUwLjUwMycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzQyODRGNDtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTcnIGQ9J00gMjEyLjEwNCwxNjcuOTUxIEwgMjEyLjg4OCwxNzUuNDc4JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojNDI4NEY0O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNycgZD0nTSAyMTIuODg4LDE3NS40NzggTCAyMTMuNjcxLDE4My4wMDUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTI1JyBkPSdNIDIxOS4wMzUsMTUwLjkgTCAyMjUuNjY1LDE0Ni4wOTMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiM0Mjg0RjQ7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTI1JyBkPSdNIDIyNS42NjUsMTQ2LjA5MyBMIDIzMi4yOTQsMTQxLjI4Nicgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTgnIGQ9J00gMjEyLjEyMywxODAuODY5IEwgMjA1LjQ5MywxODUuNjc2JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xOCcgZD0nTSAyMDUuNDkzLDE4NS42NzYgTCAxOTguODY0LDE5MC40ODMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE4JyBkPSdNIDIxNS4yMiwxODUuMTQgTCAyMDguNTksMTg5Ljk0Nycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTgnIGQ9J00gMjA4LjU5LDE4OS45NDcgTCAyMDEuOTYxLDE5NC43NTQnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE5JyBkPSdNIDIxMy42NzEsMTgzLjAwNSBMIDIyMS4zOTMsMTg2LjQ1Micgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTknIGQ9J00gMjIxLjM5MywxODYuNDUyIEwgMjI5LjExNiwxODkuODk5JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojNDI4NEY0O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yMCcgZD0nTSAyNDUuODUzLDE4Ny44ODcgTCAyNTIuNDgzLDE4My4wOCcgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzQyODRGNDtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjAnIGQ9J00gMjUyLjQ4MywxODMuMDggTCAyNTkuMTEyLDE3OC4yNzMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTIxJyBkPSdNIDI1OC4wMzcsMTgwLjY4MiBMIDI2NS43NTksMTg0LjEyOScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjEnIGQ9J00gMjY1Ljc1OSwxODQuMTI5IEwgMjczLjQ4MSwxODcuNTc2JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yMScgZD0nTSAyNjAuMTg3LDE3NS44NjUgTCAyNjcuOTA5LDE3OS4zMTInIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTIxJyBkPSdNIDI2Ny45MDksMTc5LjMxMiBMIDI3NS42MzIsMTgyLjc1OScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6Mi4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjInIGQ9J00gMjU5LjExMiwxNzguMjczIEwgMjU2LjM4LDE1Mi4wMzgnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTIzJyBkPSdNIDI1Ni4zOCwxNTIuMDM4IEwgMjMyLjI5NCwxNDEuMjg2JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoyLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yMycgZD0nTSAyNTAuNjE3LDE1NS4yNDIgTCAyMzMuNzU3LDE0Ny43MTYnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjIuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+Cjx0ZXh0IHg9JzE5NS44OTgnIHk9JzEwNS45MDInIGNsYXNzPSdhdG9tLTAnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8dGV4dCB4PScyMDMuMTc4JyB5PScxMDUuOTAyJyBjbGFzcz0nYXRvbS0wJyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+SDwvdGV4dD4KPHRleHQgeD0nMTMyLjA3NycgeT0nOTkuODQ4MScgY2xhc3M9J2F0b20tMycgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPkg8L3RleHQ+Cjx0ZXh0IHg9JzEzOC44MzMnIHk9Jzk5Ljg0ODEnIGNsYXNzPSdhdG9tLTMnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8dGV4dCB4PScxMDcuMjY2JyB5PScxNzcuMzI4JyBjbGFzcz0nYXRvbS02JyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPHRleHQgeD0nODEuNDU5OCcgeT0nMTgyLjc4NycgY2xhc3M9J2F0b20tNycgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0ZGNjBCNycgPlA8L3RleHQ+Cjx0ZXh0IHg9Jzg2LjkxODgnIHk9JzIwOC41OTMnIGNsYXNzPSdhdG9tLTgnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8dGV4dCB4PSc5NC4xOTg5JyB5PScyMDguNTkzJyBjbGFzcz0nYXRvbS04JyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+SDwvdGV4dD4KPHRleHQgeD0nNzYuMDAwOCcgeT0nMTU2Ljk4MScgY2xhc3M9J2F0b20tOScgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzU1LjY1MzgnIHk9JzE4OC4yNDYnIGNsYXNzPSdhdG9tLTEwJyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPHRleHQgeD0nMzguMDIzMScgeT0nMTY4LjYyNicgY2xhc3M9J2F0b20tMTEnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNGRjYwQjcnID5QPC90ZXh0Pgo8dGV4dCB4PSc1Ny42NDIzJyB5PScxNTAuOTk2JyBjbGFzcz0nYXRvbS0xMicgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzY0LjkyMjMnIHk9JzE1MC45OTYnIGNsYXNzPSdhdG9tLTEyJyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+SDwvdGV4dD4KPHRleHQgeD0nMTMuNjM2NCcgeT0nMTQ5LjAwNycgY2xhc3M9J2F0b20tMTMnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5IPC90ZXh0Pgo8dGV4dCB4PScyMC4zOTI0JyB5PScxNDkuMDA3JyBjbGFzcz0nYXRvbS0xMycgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzE4LjQwMzknIHk9JzE4Ni4yNTcnIGNsYXNzPSdhdG9tLTE0JyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPHRleHQgeD0nMTYwLjgzMicgeT0nMTY0LjQ1OScgY2xhc3M9J2F0b20tMTUnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8dGV4dCB4PScyMDcuNzc0JyB5PScxNjIuMDQ1JyBjbGFzcz0nYXRvbS0xNycgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzQyODRGNCcgPk48L3RleHQ+Cjx0ZXh0IHg9JzE4OS4xNTEnIHk9JzIwMy43NjMnIGNsYXNzPSdhdG9tLTE5JyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPHRleHQgeD0nMjM0LjU5MicgeT0nMTk5LjAzMicgY2xhc3M9J2F0b20tMjAnIHN0eWxlPSdmb250LXNpemU6MTBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiM0Mjg0RjQnID5OPC90ZXh0Pgo8dGV4dCB4PScyMzQuNTkyJyB5PScyMDguMzE3JyBjbGFzcz0nYXRvbS0yMCcgc3R5bGU9J2ZvbnQtc2l6ZToxMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzQyODRGNCcgPkg8L3RleHQ+Cjx0ZXh0IHg9JzI4MC4wMzMnIHk9JzE5NC4zMDEnIGNsYXNzPSdhdG9tLTIyJyBzdHlsZT0nZm9udC1zaXplOjEwcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPC9zdmc+Cg== data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0naXNvLTg4NTktMSc/Pgo8c3ZnIHZlcnNpb249JzEuMScgYmFzZVByb2ZpbGU9J2Z1bGwnCiAgICAgICAgICAgICAgeG1sbnM9J2h0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnJwogICAgICAgICAgICAgICAgICAgICAgeG1sbnM6cmRraXQ9J2h0dHA6Ly93d3cucmRraXQub3JnL3htbCcKICAgICAgICAgICAgICAgICAgICAgIHhtbG5zOnhsaW5rPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rJwogICAgICAgICAgICAgICAgICB4bWw6c3BhY2U9J3ByZXNlcnZlJwp3aWR0aD0nODVweCcgaGVpZ2h0PSc4NXB4JyB2aWV3Qm94PScwIDAgODUgODUnPgo8IS0tIEVORCBPRiBIRUFERVIgLS0+CjxyZWN0IHN0eWxlPSdvcGFjaXR5OjEuMDtmaWxsOiNGRkZGRkY7c3Ryb2tlOm5vbmUnIHdpZHRoPSc4NScgaGVpZ2h0PSc4NScgeD0nMCcgeT0nMCc+IDwvcmVjdD4KPHBhdGggY2xhc3M9J2JvbmQtMCcgZD0nTSA1MS4zNDc5LDMyLjU2NDggTCA1My4wMjQ5LDMxLjI0MDkgTCA1Mi40OTI3LDMwLjc2MDggWicgc3R5bGU9J2ZpbGw6IzNCNDE0MztmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MXB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjE7JyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0wJyBkPSdNIDUzLjAyNDksMzEuMjQwOSBMIDUzLjYzNzYsMjguOTU2OCBMIDU0LjcwMTksMjkuOTE3IFonIHN0eWxlPSdmaWxsOiNFODQyMzU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjFweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxOycgLz4KPHBhdGggY2xhc3M9J2JvbmQtMCcgZD0nTSA1My4wMjQ5LDMxLjI0MDkgTCA1Mi40OTI3LDMwLjc2MDggTCA1My42Mzc2LDI4Ljk1NjggWicgc3R5bGU9J2ZpbGw6I0U4NDIzNTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MXB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjE7JyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xJyBkPSdNIDUxLjM0NzksMzIuNTY0OCBMIDQ0LjIyMDUsMzEuODA4Nycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjQnIGQ9J00gNTEuMzQ3OSwzMi41NjQ4IEwgNTIuODMxMiwzOS41NzcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTInIGQ9J00gNDQuMjIwNSwzMS44MDg3IEwgNDMuNjU3OSwzMC4xMTQxIEwgNDMuMDM2OSwzMC40NzE5IFonIHN0eWxlPSdmaWxsOiMzQjQxNDM7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjFweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxOycgLz4KPHBhdGggY2xhc3M9J2JvbmQtMicgZD0nTSA0My42NTc5LDMwLjExNDEgTCA0MS44NTMyLDI5LjEzNTEgTCA0My4wOTUzLDI4LjQxOTYgWicgc3R5bGU9J2ZpbGw6I0U4NDIzNTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MXB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjE7JyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yJyBkPSdNIDQzLjY1NzksMzAuMTE0MSBMIDQzLjAzNjksMzAuNDcxOSBMIDQxLjg1MzIsMjkuMTM1MSBaJyBzdHlsZT0nZmlsbDojRTg0MjM1O2ZpbGwtcnVsZTpldmVub2RkO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoxcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MTsnIC8+CjxwYXRoIGNsYXNzPSdib25kLTMnIGQ9J00gNDQuMjIwNSwzMS44MDg3IEwgNDEuMjk5LDM4LjM1MzUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTQnIGQ9J00gMzguOTEyMSwzOC42MTQyIEwgMzkuMDExLDM5LjA4MTcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTQnIGQ9J00gMzYuNTI1MywzOC44NzUgTCAzNi43MjMxLDM5LjgwOTknIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTQnIGQ9J00gMzQuMTM4NSwzOS4xMzU3IEwgMzQuNDM1MSw0MC41MzgxJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNCcgZD0nTSA0MS4yOTksMzguMzUzNSBMIDQyLjk3MDIsMzkuODYxMycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTQnIGQ9J00gNDIuOTcwMiwzOS44NjEzIEwgNDQuNjQxNSw0MS4zNjknIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTUnIGQ9J00gMzQuMjg2OCwzOS44MzY5IEwgMzMuNDk4Nyw0Mi4yNTQ1JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC01JyBkPSdNIDMzLjQ5ODcsNDIuMjU0NSBMIDMyLjcxMDYsNDQuNjcyMScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNicgZD0nTSAzMC4wODYyLDQ3LjA2OTkgTCAyOC41MzQsNDcuMzk4Mycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNicgZD0nTSAyOC41MzQsNDcuMzk4MyBMIDI2Ljk4MTgsNDcuNzI2Nicgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtNycgZD0nTSAyNS43MjU3LDUxLjMxMzggTCAyNS45MzA0LDUyLjI4MTMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNGRjYwQjc7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTcnIGQ9J00gMjUuOTMwNCw1Mi4yODEzIEwgMjYuMTM1MSw1My4yNDg4JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC04JyBkPSdNIDI1LjMzNTgsNDYuMDA3MSBMIDI1LjEzNDMsNDUuMDU0OScgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtOCcgZD0nTSAyNS4xMzQzLDQ1LjA1NDkgTCAyNC45MzI5LDQ0LjEwMjcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTgnIGQ9J00gMjMuOTMzMyw0Ni4zMDM4IEwgMjMuNzMxOSw0NS4zNTE2JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC04JyBkPSdNIDIzLjczMTksNDUuMzUxNiBMIDIzLjUzMDUsNDQuMzk5NCcgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtOScgZD0nTSAyMy4wNzQsNDguNTUzMyBMIDIxLjUyMTksNDguODgxNicgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtOScgZD0nTSAyMS41MjE5LDQ4Ljg4MTYgTCAxOS45Njk3LDQ5LjIxJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMCcgZD0nTSAxNi4yNjI1LDQ3LjYzODggTCAxNS43MTI4LDQ3LjAyNycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTAnIGQ9J00gMTUuNzEyOCw0Ny4wMjcgTCAxNS4xNjMxLDQ2LjQxNTMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNGRjYwQjc7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTExJyBkPSdNIDE1LjIyOTYsNDIuNTA4NCBMIDE1Ljk0OTIsNDEuODYxNycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTEnIGQ9J00gMTUuOTQ5Miw0MS44NjE3IEwgMTYuNjY4Nyw0MS4yMTUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTEyJyBkPSdNIDExLjQ3MTgsNDIuMzA3OCBMIDEwLjkyMjEsNDEuNjk2JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMicgZD0nTSAxMC45MjIxLDQxLjY5NiBMIDEwLjM3MjQsNDEuMDg0Mycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTMnIGQ9J00gMTAuNzkyMSw0NS41MzI0IEwgMTAuMDcyNiw0Ni4xNzkxJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRkY2MEI3O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xMycgZD0nTSAxMC4wNzI2LDQ2LjE3OTEgTCA5LjM1Mjk2LDQ2LjgyNTcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTEzJyBkPSdNIDExLjc1MDMsNDYuNTk4NiBMIDExLjAzMDcsNDcuMjQ1Mycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0ZGNjBCNztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTMnIGQ9J00gMTEuMDMwNyw0Ny4yNDUzIEwgMTAuMzExMSw0Ny44OTE5JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNScgZD0nTSA0OC41OTk4LDQyLjAxNDUgTCA1MC43MTU1LDQwLjc5NTcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE1JyBkPSdNIDUwLjcxNTUsNDAuNzk1NyBMIDUyLjgzMTIsMzkuNTc3JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNicgZD0nTSA1NC4yNTU3LDQwLjQ3NDUgTCA1NC40NTA1LDQwLjAzODInIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE2JyBkPSdNIDU1LjY4MDIsNDEuMzcyIEwgNTYuMDY5Nyw0MC40OTk0JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojNDI4NEY0O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNicgZD0nTSA1Ny4xMDQ3LDQyLjI2OTUgTCA1Ny42ODksNDAuOTYwNicgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzQyODRGNDtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTcnIGQ9J00gNTkuNzA3MSw0NS42Nzc3IEwgNTkuOTEyNyw0Ny42NTI1JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojNDI4NEY0O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xNycgZD0nTSA1OS45MTI3LDQ3LjY1MjUgTCA2MC4xMTgzLDQ5LjYyNzMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTI1JyBkPSdNIDYxLjM1NTIsNDEuMDYzNSBMIDYzLjI2NjksMzkuNjc3NCcgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzQyODRGNDtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjUnIGQ9J00gNjMuMjY2OSwzOS42Nzc0IEwgNjUuMTc4NiwzOC4yOTEzJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xOCcgZD0nTSA1OS42OTc2LDQ5LjA0NzEgTCA1Ny43ODU5LDUwLjQzMzEnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE4JyBkPSdNIDU3Ljc4NTksNTAuNDMzMSBMIDU1Ljg3NDIsNTEuODE5Micgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTgnIGQ9J00gNjAuNTM5LDUwLjIwNzYgTCA1OC42MjczLDUxLjU5MzcnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTE4JyBkPSdNIDU4LjYyNzMsNTEuNTkzNyBMIDU2LjcxNTYsNTIuOTc5OCcgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6I0U4NDIzNTtzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMTknIGQ9J00gNjAuMTE4Myw0OS42MjczIEwgNjIuNDAxMSw1MC42NDY0JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0xOScgZD0nTSA2Mi40MDExLDUwLjY0NjQgTCA2NC42ODM5LDUxLjY2NTQnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiM0Mjg0RjQ7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTIwJyBkPSdNIDY4LjY0MjMsNTEuMTEzOSBMIDcwLjU1NCw0OS43Mjc4JyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojNDI4NEY0O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yMCcgZD0nTSA3MC41NTQsNDkuNzI3OCBMIDcyLjQ2NTcsNDguMzQxNycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjEnIGQ9J00gNzIuMTczNSw0OC45OTYyIEwgNzQuNDU2NCw1MC4wMTUyJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojM0I0MTQzO3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yMScgZD0nTSA3NC40NTY0LDUwLjAxNTIgTCA3Ni43MzkyLDUxLjAzNDMnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiNFODQyMzU7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTIxJyBkPSdNIDcyLjc1NzksNDcuNjg3MiBMIDc1LjA0MDcsNDguNzA2Micgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjEnIGQ9J00gNzUuMDQwNyw0OC43MDYyIEwgNzcuMzIzNSw0OS43MjUzJyBzdHlsZT0nZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojRTg0MjM1O3N0cm9rZS13aWR0aDoxLjBweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxJyAvPgo8cGF0aCBjbGFzcz0nYm9uZC0yMicgZD0nTSA3Mi40NjU3LDQ4LjM0MTcgTCA3MS43MjM0LDQxLjIxMjknIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+CjxwYXRoIGNsYXNzPSdib25kLTIzJyBkPSdNIDcxLjcyMzQsNDEuMjEyOSBMIDY1LjE3ODYsMzguMjkxMycgc3R5bGU9J2ZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzNCNDE0MztzdHJva2Utd2lkdGg6MS4wcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MScgLz4KPHBhdGggY2xhc3M9J2JvbmQtMjMnIGQ9J00gNzAuMTU3NCw0Mi4wODM2IEwgNjUuNTc2LDQwLjAzODUnIHN0eWxlPSdmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMzQjQxNDM7c3Ryb2tlLXdpZHRoOjEuMHB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjEnIC8+Cjx0ZXh0IHg9JzU0LjM0ODknIHk9JzMwLjI0MzEnIGNsYXNzPSdhdG9tLTAnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzU4LjQ4ODknIHk9JzMwLjI0MzEnIGNsYXNzPSdhdG9tLTAnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPkg8L3RleHQ+Cjx0ZXh0IHg9JzM1LjAwMDknIHk9JzI4LjU5ODEnIGNsYXNzPSdhdG9tLTMnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPkg8L3RleHQ+Cjx0ZXh0IHg9JzM4Ljg0MjknIHk9JzI4LjU5ODEnIGNsYXNzPSdhdG9tLTMnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzMwLjI2NTQnIHk9JzQ5LjY1MTInIGNsYXNzPSdhdG9tLTYnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzIzLjI1MzInIHk9JzUxLjEzNDYnIGNsYXNzPSdhdG9tLTcnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0ZGNjBCNycgPlA8L3RleHQ+Cjx0ZXh0IHg9JzI0LjczNjYnIHk9JzU4LjE0NjcnIGNsYXNzPSdhdG9tLTgnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzI4Ljg3NjYnIHk9JzU4LjE0NjcnIGNsYXNzPSdhdG9tLTgnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPkg8L3RleHQ+Cjx0ZXh0IHg9JzIxLjc2OTknIHk9JzQ0LjEyMjUnIGNsYXNzPSdhdG9tLTknIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzE2LjI0MTEnIHk9JzUyLjYxOCcgY2xhc3M9J2F0b20tMTAnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzExLjQ1MDQnIHk9JzQ3LjI4NjknIGNsYXNzPSdhdG9tLTExJyBzdHlsZT0nZm9udC1zaXplOjZweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNGRjYwQjcnID5QPC90ZXh0Pgo8dGV4dCB4PScxNi43ODE0JyB5PSc0Mi40OTYyJyBjbGFzcz0nYXRvbS0xMicgc3R5bGU9J2ZvbnQtc2l6ZTo2cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPHRleHQgeD0nMjAuOTIxNCcgeT0nNDIuNDk2MicgY2xhc3M9J2F0b20tMTInIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPkg8L3RleHQ+Cjx0ZXh0IHg9JzIuODE3NjknIHk9JzQxLjk1NTknIGNsYXNzPSdhdG9tLTEzJyBzdHlsZT0nZm9udC1zaXplOjZweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5IPC90ZXh0Pgo8dGV4dCB4PSc2LjY1OTcnIHk9JzQxLjk1NTknIGNsYXNzPSdhdG9tLTEzJyBzdHlsZT0nZm9udC1zaXplOjZweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8dGV4dCB4PSc2LjExOTM3JyB5PSc1Mi4wNzc2JyBjbGFzcz0nYXRvbS0xNCcgc3R5bGU9J2ZvbnQtc2l6ZTo2cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojRTg0MjM1JyA+TzwvdGV4dD4KPHRleHQgeD0nNDQuODIwNicgeT0nNDYuMTU0NicgY2xhc3M9J2F0b20tMTUnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6I0U4NDIzNScgPk88L3RleHQ+Cjx0ZXh0IHg9JzU3LjU3NicgeT0nNDUuNDk4NScgY2xhc3M9J2F0b20tMTcnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzQyODRGNCcgPk48L3RleHQ+Cjx0ZXh0IHg9JzUyLjUxNTcnIHk9JzU2LjgzNDUnIGNsYXNzPSdhdG9tLTE5JyBzdHlsZT0nZm9udC1zaXplOjZweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8dGV4dCB4PSc2NC44NjMxJyB5PSc1NS41NDg5JyBjbGFzcz0nYXRvbS0yMCcgc3R5bGU9J2ZvbnQtc2l6ZTo2cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojNDI4NEY0JyA+TjwvdGV4dD4KPHRleHQgeD0nNjQuODYzMScgeT0nNjAuODI4OScgY2xhc3M9J2F0b20tMjAnIHN0eWxlPSdmb250LXNpemU6NnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzQyODRGNCcgPkg8L3RleHQ+Cjx0ZXh0IHg9Jzc3LjIxMDUnIHk9JzU0LjI2MzMnIGNsYXNzPSdhdG9tLTIyJyBzdHlsZT0nZm9udC1zaXplOjZweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiNFODQyMzUnID5PPC90ZXh0Pgo8L3N2Zz4K O[C@@H]1[C@H](O)[C@@H](COP(O)(=O)OP(O)(O)=O)O[C@H]1N1C(=O)NC(=O)C=C1 XCCTYIAWTASOJWXVFCMESISAN 0.000 description 1
 230000003247 decreasing Effects 0.000 description 1
 238000003780 insertion Methods 0.000 description 1
 238000011084 recovery Methods 0.000 description 1
 230000003362 replicative Effects 0.000 description 1
 230000003313 weakening Effects 0.000 description 1
Images
Classifications

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
 H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, nonrepudiation, key authentication or verification of credentials
 H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, nonrepudiation, key authentication or verification of credentials using cryptographic hash functions
 H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, nonrepudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBCMAC or HMAC

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
 H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, nonrepudiation, key authentication or verification of credentials
 H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, nonrepudiation, key authentication or verification of credentials involving digital signatures

 G—PHYSICS
 G11—INFORMATION STORAGE
 G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
 G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
 G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy

 G—PHYSICS
 G11—INFORMATION STORAGE
 G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
 G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
 G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
 G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
 H04L2209/30—Compression, e.g. MerkleDamgard construction

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
 H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
 H04L2209/38—Chaining, e.g. hash chain or certificate chain

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
 H04L2209/80—Wireless

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
 H04N7/00—Television systems
 H04N7/16—Analogue secrecy systems; Analogue subscription systems
 H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
 H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
Abstract
Description
 This application claims the benefit of Provisional Application No. 60/495,787, filed Aug. 15, 2003. The present application incorporates the disclosure of this provisional application by reference.
 1. Field of the Invention
 The present invention relates to data stream authentication, and more specifically to authentication schemes with adaptively controlled packet loss.
 2. Description of the Related Art
 In many cases, it is desirable to append authentication information to a stream of data to assure a recipient that the data came from a specific source and was not modified enroute. For example, if the data is being provided to an application, then it would be important for the application that the data has not been corrupted either maliciously or by accident.
 In cryptography, there are two traditional mechanisms for permitting such authentication:
 1. Message Authentication Codes (MAC)
 2. Digital Signatures
 With a MAC, both the original source and the ultimate receiver must possess knowledge of a shared secret key. The sender applies a mathematical transformation involving the original data and secret key, and produces a tag. The receiver can then apply a similar transformation with the data, the tag, and the secret key to verify the origin and the integrity of the data.
 With Digital Signatures, the key is split into two parts: a secret signing key and a public verification key. The public verification key can be used to verify anything signed using the secret signing key. The key is split in such a way that it is not possible to derive the private portion from the public portion. The sender applies a mathematical transformation involving the original data and secret signing key, and produces a signature. The recipient can then apply a similar transformation with the data, the signature, and the public verification key to ascertain the identity of the sender and the integrity of the data.
 Digital signatures have a nonrepudiation property that MACs do not. Namely, the signer cannot later deny having signed the document since the signing key is secret and was in the signer's possession. Of course, the signature owner can always claim that the secret signing key was stolen by some adversary.
 Because of their nature, traditional authentication schemes do not tolerate any transformations to the data made by the source or by an intermediate. If a document is modified after it is signed, the verification step will so indicate, and will fail.
 But for many applications, it is not only convenient, but sometimes necessary, to permit some specific types of modifications. For example, scalable video coding schemes, a highlevel picture of the principle of which is shown in
FIG. 1 , have the property that a subset of the stream can be decoded and the quality is commensurate with the amount decoded. These schemes may encode video into a base layer and then zero or more “enhancement” layers. Just the base layer alone would be sufficient to view the stream. Enhancement layers are utilized to improve the overall quality.  Now, in an environment that is resource constrained, one might want to strip the enhancement layers and only send the base layers. If the entire stream has been digitally signed or authenticated in conventional ways, then by removing the enhancement layers, the original tag or signature becomes invalid. Thus the entire stream would have to be reauthenticated.
 Alternatively, one may want to splice several streams of different qualities as in a simulcast situation. There may be one highquality version of the stream, one mediumquality version of the stream, and one lowquality version of the stream. If network resources are available, then the highquality stream may be sent, but if the network congestion goes up, then one may want to shift to the medium or low quality streams. In an alternate scenario, it could be the case that the receiver is mobile and is leaving one network environment and entering another that has different resource restrictions. The splicing situation can be considered a special case of a lossy situation where the quality of signal transmission is poor or otherwise is degraded, for example, by viewing the three data streams as one huge layered stream and imagining that two out of three frames are being discarded.
 Yet another application is dynamic advertising. A source may include in a given slot a number of advertisements that can be displayed. An intermediary can then choose from among these choices which advertisement it would like to display. The choice can, for example, be based upon what the intermediary thinks will be the best advertisement for the target audience. The advertisements themselves can be created by an intermediary or some other party, and can be provided to the source either in their original form or may be hashed. The source would then include them when signing the stream.
 Thus, signature schemes that can handle these types of losses in a secure manner are needed. Here, “secure” means that the ultimate end receiver can determine with overwhelmingly high confidence that the data it receives comes from a stream that was originally signed validly, but for which certain portions were removed. In addition, there is also a need for an intermediary that can adaptively and intelligently decide which blocks to drop.
 One conventional solution to the controlled loss authentication problem is to authenticate each packet individually. This solution has two substantial drawbacks. First, in the case of using digital signatures, a fairly expensive computation must be performed for each packet. Second, in both the digital signature and MAC case, authentication information must be appended to each packet, which may not be feasible in consideration of efforts to remove portions of the stream stem to meet bandwidth constraints. levels. Then, the decoder 984 is designed to select one of the tone voltages of 64 IEEE/ACM Transactions on Networking, 7(4):502:513, August 1999, the authors propose a solution in which each data element is hashed, and then the resulting hashes are digested using a Merkletree. The root of the Merkle tree is authenticated. Then, with each data element, the conodes are sent, thereby allowing the receiver to authenticate without it. Since Wong and Lam deal with perpacket authentication, each packet contains authentication information. In particular, if v is the size, in bytes, of a Merkle tree node, h is the height of the Merkle tree, then each data element transmitted must be accompanied by v×h bytes. Thus, this approach does not deal with the controlled loss authentication problem, and is not bandwidth efficient.
 In R. Johnson, D. Molnar, D. Song, and D. Wagner, Homomorphic Signature Schemes—RSA 2002, Cryptographer's Track, the authors propose a redactable signature scheme. It permits certain specific transformations on the data while still allowing the receiver to verify. It also allows arbitrary deletion of substrings in a signed document and has applications for censoring. Suppose n message blocks m=m_{1}, . . . , m_{n }are to be signed, and assume that n is a power of 2. The scheme starts with an initial secret key k and uses it to generate n keys k_{1}, . . . , k_{n }with the aid of a treelike construction such as that of Goldreich, Goldwasser, and Micali (GGM), O. Goldreich, S. Goldwasser, and S. Micali, How to Construct Random Functions, Journal of the ACM, vol. 33, No. 4, 1986, pages 210217. Then, to sign message m, the triplets (0, m_{1}, k_{1}), . . . , (0, m_{n}, k_{n}) are hashed in a Merklelike tree and the root r is signed to produce the signature s. The difference between this tree and a regular Merkle tree is that the value 1 is prepended before the internal hashes are computed. With knowledge of k, anyone can verify s. However, in order to censor the data stream, the value of k is never published. Instead, only certain intermediate values of the GGM tree are published. These values correspond to the information needed to derive the final keys k_{i }corresponding to the data elements which are not censored. With uncensored blocks, the intermediate GGM values, and the conodes in the Merklelike tree, the signature can be verified. However, the above Homomorphic Signature Scheme takes precautions, via a GGM tree, to protect the confidentiality of censored data and requires all uncensored message blocks, all conodes, and all keying information in order to permit verification, and thus is not efficient.
 Accordingly, there has been a need for a secure authentication scheme that permits controlled removal of certain blocks in a stream without weakening the receiver's ability to verify the authentication information, and without requiring confidentiality of censored data.
 In view of the foregoing, it is an object of the present invention to provide schemes for secure authentication under adaptive data loss both in the symmetric setting (with MAC) or in the asymmetric setting (with digital signatures), which are efficient with respect to the computation requirements of the sender, receiver, and intermediary, as well as the bandwidth requirements of the channels over which these parties communicate.
 Briefly, the present invention addresses the following problems:
 1. adaptive loss (subsequence) authentication, wherein data chunks are removed arbitrarily;
 2. simulcast authentication, wherein several data streams are intertwined and only one data chunk is taken at a time from a given stream, and the data from the other streams is dropped; and
 3. adaptively lossy simulcast authentication, wherein sometimes the entire data chunk is dropped altogether.
 The present invention provides the following schemes:
 1. Linear Scheme for Subsequence Authentication;
 2. Linear Scheme for Simulcast Authentication;
 3. Tree Scheme for Subsequence Authentication; and
 4. Tree Scheme for Simulcast Authentication.
 Each of the above schemes may incorporate either a digital signature or a MAC. Therefore, the present invention implicitly provides 8 (=4×2) schemes.
 The schemes use cryptographic hash functions to process the blocks of the original stream and create a short digest. A digital signature or MAC is then applied to the digest, thereby providing authentication information. If the receiver is given the entire stream, then it can recompute the digest and verify the signature. When specific portions of the stream need to be removed, the remover sends information that allows the receiver to efficiently compute the digest. The amount of information provided to the receiver in this setting is related to the output size of the cryptographic hash function and is otherwise independent of the actual data stream.
 According to one aspect of this invention, Linear Scheme for Subsequence Authentication, the intermediary or source can remove arbitrary blocks (irrespective of their location) while still permitting the receiver to authenticate information. The scheme involves computing a twolayer hash chain and providing the recipient with various values in this chain. The scheme is online for the receiver in the sense that the receiver does not have to incur any delay in verifying the authentication information. In an optimization and generalization to this scheme, one second layerhash is computed for every bundle of r firstlayer hashes. When r=1, the scheme is the original linear scheme for subsequence authentication. In an improvement to this scheme, several firstlayer hashes are aggregated before performing the secondlayer hash. Consequently, fewer secondlayer hashes need to be performed.
 According to a second aspect of this invention, Linear Scheme for Simulcast Authentication, the intermediary or source is provided with multiple streams and can arbitrarily switch among which stream it transmits while still permitting the receiver to authenticate information. The scheme involves computing a multilayer hash chain and providing the recipient with various values in this chain. The scheme is online for the tone power source lines by ½, ¼, ⅛, . . . . Then, the area occupied by the authentication information.
 According to a third aspect of this invention, Tree Scheme for Subsequence Authentication, the intermediary or source can remove arbitrary blocks (irrespective of their location) while still permitting the receiver to authenticate information. The scheme involves computing a hash tree and providing the recipient with various values in this tree. In the case that some subset (of size greater than one) of dropped blocks constitute a subtree of the hash tree, the hashed scheme is more efficient with respect to bandwidth than the corresponding linear scheme. The scheme is not online for the receiver in the sense that the receiver must wait for all blocks before being able to verify the authentication information.
 According to a fourth aspect of this invention, Tree Scheme for Simulcast Authentication, the intermediary or source is provided with multiple streams and can arbitrarily switch among which stream it transmits while still permitting the receiver to authenticate information. The scheme involves computing a hash tree and providing the receiver with various values in this tree. The scheme is not online for the receiver in the sense that the receiver must wait for all blocks before being able to verify the authentication information.
 In all aspects of this invention, it is assumed that the sender has possession of all data to be signed at the onset. In most cases, such as when media is prerecorded, this will not be a concern. In the case of a live stream, the present invention breaks the stream into smaller chunks and applies the schemes specified herein. Those skilled in the art will recognize that variations and modifications can be made without departing from the spirit of the invention.
 The present invention permits a situation in which an intermediary may adaptively and intelligently decide which blocks are to be dropped. The schemes of the present invention readily adapt to any model for dropping blocks. Moreover, the intermediary is not required to know of any cryptographic keying material. Furthermore, if the source provides the intermediary with various hash values, then the intermediary can avoid having to do any cryptographic related computation. Instead, it just has to forward the blocks it desired together with the hash information for those blocks that are dropped.
 All of the inventive schemes have the property that, given knowledge ahead of time that a given block will not be dropped, then the first layer hash on that block will not be performed. That is, the first layer hash for just that block can be replaced with the identity function (h(x)=x).
 Both the linear and treebased schemes can take advantage of correlation among blocks of data. For example, in the treebased scheme, if a given subset of blocks has the behavior that all will be dropped or all will be kept, then these blocks can be placed as all the leaves of the same subtree. In the event that all packets in the given subset are dropped, only the root has to be transmitted. However, this concept applies even if the correlation is probabilistic. For example, if a given block being dropped makes it more likely that another block will be dropped, then these blocks should also be clustered. Likewise, in the linear schemes, if a given sequence of frames are to be all kept or dropped, these frames can be treated as a single block unit to be hashed. Then, if the entire sequence of frames is dropped only a single hash value needs to be sent.
 The present invention is described herein with reference to the accompanying drawings, similar reference numbers being used to indicate functionally similar elements.

FIG. 1 shows a highlevel depiction of a scalable coder. 
FIG. 2 shows a block diagram of a sender or source. 
FIG. 3 shows a block diagram of a receiver. 
FIG. 4 shows a block diagram of an intermediary. 
FIG. 5 shows a block diagram of a system including a sender, a receiver, and an intermediary. 
FIG. 6 illustrates a Merkle Tree with eight leaves. 
FIG. 7 illustrates a basic linear subsequence authentication scheme according to one embodiment of the present invention. 
FIG. 8 illustrates an optimized linear subsequence authentication scheme with r=3 and with n a multiple of r, according to one embodiment of the present invention. 
FIG. 9 illustrates a basic linear simulcast authentication scheme according to one embodiment of the present invention. 
FIG. 10 illustrates a treebased subsequence authentication scheme according to one embodiment of the present invention. 
FIG. 11 illustrates a treebased simulcast authentication scheme according to one embodiment of the present invention.  In the schemes of the present invention, an initial sender 200 in
FIG. 2 is responsible for authenticating the data stream. As shown, each sender 200 includes a processor 201 in bidirectional communication with a memory 202. The processor 201 executes program code for carrying out the schemes of the present invention to generate, transmit or receive data streams. The memory 202 stores cryptographic keys, program codes, as well as intermediate results and other information used during execution of the schemes. A communications network 203 is provided over which the sender may communicate with receivers. 
FIG. 3 shows a block diagram of a receiver which receives data streams from the sender or server or an intermediary over a communication network according to one embodiment of the present invention. The system of the present invention includes a number of receivers, which verify the received data. Each receiver 300 includes a processor 301 in bidirectional communication with a memory 302. The processor 301 executes program code for carrying out the schemes of the present invention to generate, transmit, and receive data streams. Program code may be created according to methods known in the art. The memory 302 stores cryptographic keys and the program code, as well as intermediate results and other information used during execution of the schemes.  A communications network 303 is provided over which the sender and the receivers may communicate. The communications network may be of various common forms, including, for example, a local area network (LAN), a wide area network (WAN), and/or a mobile telephone network. The network may permit either wired or wireless communications.

FIG. 4 shows a block diagram of an intermediary. There may be more than one intermediary; alternatively, the source and intermediary may be identical. If the intermediary and source are not identical, then the intermediary needs not have any cryptographic keying material. The data for the sender may pass through one or more intermediaries shown inFIG. 4 on its way to the sender or receiver. The intermediaries may choose to perform certain transformations on the data. Each intermediary 400 includes a processor 401 in bidirectional communication with a memory 402. The processor 401 executes program code for carrying out the schemes of the present invention to generate, transmit, and receive data streams. The memory 402 may store cryptographic keys. 
FIG. 5 shows a block diagram of a system according to one embodiment of the present invention, including a sender 501, an intermediary 503, a receiver 505, and communication networks 502 and 504. As shown, the sender 501 transmits an original data stream with signature and optional helper information to the intermediary 503 via the communication network 502, which then transmits a reduced data stream with signature and relevant helper information to receiver 505 via communication network 504.  The abovementioned transformations involve removing certain portions of the data. If an intermediary modifies the data stream, it will determine what information, if any, is required by the receiver to verify the authentication information associated with the stream.
 M denotes a media stream that can be broken up into it blocks of length b: M=M_{1}M_{2 }. . . M_{n}, M_{i}=b, 1≦i≦n. H denotes a cryptographic compression function that takes as input a bbit payload as well as a vbit initialization vector or IV, and produces a vbit output where typically v<b. These cryptographic compression functions are collision resistant, that is, it is hard to find two inputs m_{1 }and m_{2 }with m_{1}≠m_{2 }such that H(IV,m_{1})=H(IV, m_{2}) for a fixed IV. It is assumed that there is a standard IV, called IV_{0}, that is fixed and publicly known. For notational simplicity, the description below will not explicitly list the IV as an argument in the hash function—though it should be thought of as being there implicitly.
 Examples of such cryptographic compression functions are found in SHA1 or MD5. The compression function in SHA1 has an output and IV size of 160bits whereas the compression function in MD5 works with 128bit values. Both allow for a 512bit payload size. When it is necessary to operate on data blocks that are larger than the payload size, application of the compression function is repeated. Functions that operate as such while still retaining the collision resistance property are termed cryptographic hash functions. For simplicity, this term is used below even if a data block that fits within the payload is dealt with.
 For the schemes involving digital signatures, it is assumed that a publickey infrastructure exists, and that the sender has a key pair (Pk, Sk). Sk is the sender's private signing key—which can be used for appending a digital signature to a message, and Pk is the sender's public verification key which can be used to verify the authenticity of any signature issued using Pk. σ(Sk, M) denotes the digital signature algorithm on message M under signing key Sk, and v(Pk, M, σ) denotes the verification algorithm. The intermediate does not need to know either the signing or the verification key. For the schemes involving MAC, it is assumed that both the initial sender S and the ultimate receiver R share knowledge of a symmetric key, which need not be known by the intermediaries.
 The schemes of the present invention make use of conventional constructs involving cryptographic compression functions. One such construct is an iterated hash function which is built from cryptographic compression functions as follows. Suppose a message M can be broken up into n blocks of length b, and H is a cryptographic compression function with a bbit payload and a vbit output. The iterated hash function defined by H is the value x_{n }where:
$\begin{array}{c}{x}_{1}=H\text{\hspace{1em}}\left({\mathrm{IV}}_{0},{M}_{1}\right)\\ {x}_{2}=H\text{\hspace{1em}}\left({x}_{1},{M}_{2}\right)\\ \text{\hspace{1em}}\vdots \\ {x}_{n}=H\text{\hspace{1em}}\left({x}_{n1},{M}_{n}\right)\end{array}$  Assuming that it is hard to find collisions in the compression function H, it is then hard to find collisions in the iterated hash. Typically, when one wants to digitally sign a message, an iterated hash is applied to the message, and the resulting output is signed. The methods, systems, and components of the present invention will involve similar constructions, but intermediate values will be provided to aid in verification.
 Another conventional construct involving cryptographic compression functions is a Merkle tree.
FIG. 6 shows a graphical depiction of a Merkle tree with eight leaves. Each leaf is the hash of the message below it. Each interior node represents the hash of its children. The root is signed. Suppose that M can be broken up into n blocks M=M_{1 }. . . M_{n}. For least 2K bits so that voltages of 4^{K }different voltage levels can be output from the incorporate powers other than 2. The Merkle tree associated with M under hash function H is a binary tree in which each node is associated with a specific value. There are n leaves, and each leaf l_{i }takes on the hash of M_{i}—that is, H(IV_{0}, M_{i}). Each interior (nonleaf) node then takes on the value associated with the hash of the concatenations of the values of its two children. That is, if vertex v has children v_{1 }and v_{2 }where v_{1 }has value x_{1 }and v_{2 }has value x_{2}, then the value associated with v is H(IV_{0}, x_{1 }x_{2}).  the selection circuit receives as input first through mth (=2^{K}, where K is a root of the tree associated with the message M forming the digest is signed. If the underlying compression or hash function is collision resistant, then it will be hard to find two different messages whose Merkle root value is identical.
 The present invention also makes use of the notion of the conodes for a given vertex in a Merkle tree. The conodes of a vertex v consist of the direct siblings of the vertices on the path from v to the root. Given a vertex v and its conodes, one can compute the sequence of hash functions that lead from v to the root.
 1. Subsequence Authentication
 The linear subsequence authentication scheme of the present invention allows stream authentication even when arbitrary blocks from the message are removed. As long as the blocks sent by an intermediate node are a proper subsequence of the original message, the receiver can authenticate the stream.
 1.1 Signing

FIG. 7 illustrates a basic linear subsequence authentication scheme according to one embodiment of the present invention. Given a message M, signature generation follows a similar paradigm to an iterated hash, except that it uses “two hashing layers”.  Given a message M=M_{1}M_{2 }. . . M_{n}, in one embodiment, the present invention generates partial hash computations h_{1}, . . . , h_{n }as follows:
$\begin{array}{cc}\begin{array}{c}{h}_{0}={\mathrm{IV}}_{0}\\ {g}_{1}=H\text{\hspace{1em}}\left({h}_{0},{M}_{n}\right)\\ {h}_{1}=H\text{\hspace{1em}}\left({h}_{0},{g}_{1}\right)\\ {g}_{2}=H\text{\hspace{1em}}\left({h}_{1},{M}_{n1}\right)\\ {h}_{2}=H\text{\hspace{1em}}\left({h}_{1},{g}_{2}\right)\\ \text{\hspace{1em}}\vdots \\ {g}_{n}=H\text{\hspace{1em}}\left({h}_{n1},{M}_{1}\right)\\ {h}_{n}=H\text{\hspace{1em}}\left({h}_{n1},{g}_{n}\right)\end{array}& \left(1\right)\end{array}$  In the process of computing h_{1}, . . . , h_{n}, the scheme shown in
FIG. 7 computes auxiliary hash values g_{1}, . . . , g_{n }which are not sent. The initial sender S transmits (M, σ_{Sk}(h_{n})). The value of IV_{0 }can be used as the IV for the computation of all the g_{i }values. 
 1.2 Signature Update
 If an intermediate node wants to strip off k arbitrarily located message blocks, the node generates a resulting “message” M′, identical to M but where k blocks have been removed. The receiver needs to be able to authenticate M′.
 Given the received nblock message M, the intermediate node computes “new” blocks M_{1}′, . . . , M_{n}′. For each message block M_{n−i+1 }(starting from the end, i=1 to i=n), the intermediate node computes the corresponding auxiliary and partial hashes as follows:
g _{i} =H(h _{i−1} , M _{n−i+1}),
h _{i} =H(h _{i−1} , g _{i}) (2)  Depending on whether the block will be forwarded or dropped, the intermediate node computes
M′ _{n−i+1} =M _{n−i+1}, if block M _{i }is forwarded, or g _{i}, if block M _{i }is dropped (3) 
 Some standard encoding is applied to the block contents to facilitate distinguishing between “message blocks” and “hashes”. Skilled artisans would appreciate that there are numerous ways to perform this encoding.

 1.3 Verification
 The receiver can verify the signature by computing h_{n }from M_{1}′, . . . , M_{k}′ and h_{n−t }as follows: for each message block M′_{n−i+1 }(starting from the end, i=1 to i=n), and depending on whether the received block is a “message block” or a “hash”, it computes
h _{i} =H(h _{i−1} , H(h _{i−1} , M′ _{n−i+1})), if M′ _{n−i+1 }is a “message block” H(h _{i−1} , M′n−i+1 )), if M′ _{n−i+1 }is a “hash” (4)  The receiver can then verify the signature on h_{n }as normal using the verification algorithm v.
 The alternative online verification proceeds as follows: the receiver computes the partial hash h_{n }from (M′_{1}, h_{n−1}) using relation (4) and then it verifies the signature on the partial hash h_{n}. Afterwards, for i=2, . . . , n, it computes the partial hash h_{i }from (M′_{i}, h_{n−i}) using (4) and verifies that the so computed hash matches the hash value received in iteration i−1.
 1.4 Security
 As mentioned above, the iterated hash construction is collision resistant so long as the underlying hash function H is as well. In particular, if one finds a collision in the iterated construction, then at some point there is an internal collision, which means one can find a collision on the hash function H. If an adversary can come up with a nonsubsequence forgery (that is, a message/signature pair that is not obtained by merely taking a subsequence of the original message), then it is possible to show that one can demonstrate either a collision in the hash function or a forgery on the underlying signature scheme. Therefore, as long as the signature scheme is not easily susceptible to forgery and the hash function is not easily susceptible to collisions, the scheme presented above is secure.
 1.5 Performance
 When the intermediary removes blocks, it only needs to compute the hash of the block being removed. This computation does not involve any publickey steps and is fairly efficient. In fact, the throughput of algorithms like SHA1 is on the order of a few hundred megabits per second. Moreover, if the intermediate nodes are resource bounded with respect to computation, the source can follow the alternative approach and include the intermediate h_{i }values. In the case of SHA1, each such value is 20bytes long, so the bandwidth overhead will likely be quite small.
 A tradeoff between bandwidth usage and buffering/computation is possible by sending some intermediate h_{i }values selectively. If the receiver can store up to b message blocks, then the intermediate node can send the hash value h_{n−b }only after b message blocks. Authentication can be done as described above starting from h_{n−b}. Then, the intermediate node sends a second “bundle” (next b message blocks and h_{n−2b}), which is authenticated by recomputing the partial hashes h_{n−b}, . . . , h_{n−2b+1 }and then verifying the recomputed hash value h_{n−b }matching the one received in the first bundle.
 The computations of this embodiment do not require storing the entire stream in memory since only a single input block to the hash function is needed at any given time.
 The scheme of the first embodiment permits the role of an intermediary which can adaptively and intelligently choose to remove any number of blocks without requiring knowledge of any cryptographic keying material. Moreover, the intermediary can be proximate to the receiver and can control the loss (and therefore the amount of hash information) dynamically. Furthermore, the authentication information can be verified in an online manner by the receiver. That is, the receiver can verify the authentication information as it receives the stream, and will not be required to do any form of extensive buffering. Also, the first layer hash computations are not required for any block that will not be dropped. For example, an MPEG Iframe or the base layer of a scalable coding scheme will not be intentionally dropped. For these blocks, only the second layer is required. In this instance, the first layer hash function for that block can be replaced with the identity function h(x)=x. In a similar spirit, if a given sequence of frames will either all be dropped or all be kept, then the above scheme is even more advantageous since it can cluster these as a single block before hashing.
 2. An Efficiency Improvement to the Subsequence Authentication
 The second embodiment of the present invention provides an efficiency improvement to the basic linear subsequence authentication, by aggregating several first layer hashes before performing the second layer hashes. As a result, the method according to the second embodiment performs fewer second layer hashes. For a typical compression function, such as the one accompanying SHA1, the payload size is 64 bytes whereas the digest size is 20 bytes. As a result, in this situation, three digests can be concatenated together before the second layer function is called. In the second embodiment, it is assumed that r hashes are aggregated. In addition, for any decimal number a, └a┘ denotes the smallest integer greater or equal than a, and ┌a┐ denotes the largest integer less or equal than a.
 2.1 Signing
 For a message M, signature generation according to the second embodiment follows a similar paradigm to the scheme of the first embodiment, and uses “two hashing layers”. However, the scheme of the second embodiment involves fewer hashes than that of the first embodiment.
FIG. 8 shows an improved linear subsequence authentication scheme according to one embodiment of the present invention, with r=3 and with n a multiple of r. In this scheme groups of r firstlayer hashes are hashed in the second layer. Given a message M=M_{1}M_{2 }. . . M_{n}, the scheme of the second embodiment generates the partial hash computations h_{1}, . . . , h_{m}, where$m=\lceil \frac{n}{r}\rceil \text{\hspace{1em}}\mathrm{as}\text{\hspace{1em}}\mathrm{follows}\text{:}$ $\begin{array}{cc}\begin{array}{c}{g}_{1}=H\left({\mathrm{IV}}_{0},{M}_{n}\right)\\ {g}_{2}=H\left({\mathrm{IV}}_{0},{M}_{n1}\right)\\ \vdots \\ {g}_{r}=H\left({\mathrm{IV}}_{0},{M}_{n\left(r1\right)}\right)\\ {h}_{1}=H\left({\mathrm{IV}}_{0},{g}_{1},\dots \text{\hspace{1em}},{g}_{r}\right)\\ {g}_{r+1}=H\left({\mathrm{IV}}_{0},{M}_{nr}\right)\\ {g}_{r+2}=H\left({\mathrm{IV}}_{0},{M}_{n\left(r+1\right)}\right)\\ \vdots \\ {g}_{2r}=H\left({\mathrm{IV}}_{0},{M}_{n\left(2r1\right)}\right)\\ {h}_{2}=H\left({h}_{1},{g}_{r+1},\dots \text{\hspace{1em}},{g}_{2r}\right)\\ \vdots \\ {g}_{r\lfloor \frac{n}{r}\rfloor r+1}=H\left({\mathrm{IV}}_{0},{M}_{n\left(r\lfloor \frac{n}{r}\rfloor r\right)}\right)\\ {g}_{r\lfloor \frac{n}{r}\rfloor r+2}=H\left({\mathrm{IV}}_{0},{M}_{n\left(r\lfloor \frac{n}{r}\rfloor r+1\right)}\right)\\ \vdots \\ {g}_{r\lfloor \frac{n}{r}\rfloor}=H\left({\mathrm{IV}}_{0},{M}_{n\left(r\lfloor \frac{n}{r}\rfloor 1\right)}\right)\\ {h}_{m1}=H\left({h}_{m2},{g}_{r\lfloor \frac{n}{r}\rfloor r+1},\dots \text{\hspace{1em}},{g}_{r\lfloor \frac{n}{r}\rfloor}\right)\\ {g}_{r\lfloor \frac{n}{r}\rfloor +1}=H\left({\mathrm{IV}}_{0},{M}_{n\left(r\lfloor \frac{n}{r}\rfloor \right)}\right)\\ \vdots \\ {g}_{n}=H\left({\mathrm{IV}}_{0},{M}_{1}\right)\\ {h}_{m}=H\left({h}_{m1},{g}_{r\lfloor \frac{n}{r}\rfloor +1},\dots \text{\hspace{1em}},{g}_{n}\right)\end{array}& \left(5\right)\end{array}$  Similarly to the scheme of the first embodiment, in the process of computing h_{1}, . . . , h_{m}, the scheme of the second embodiment computes auxiliary hash values g_{1}, . . . , g_{n }which are not sent. The initial sender transmits (M, σ_{Sk}(h_{m})), and the value of IV_{0 }can be used as the IV for the computation of all the g_{i }values.

 2.2 Signature Update
 Now, suppose an intermediate node wants to strip off n−k arbitrarily located message blocks. It generates a resulting “message” M′, identical to M but where n−k blocks have been removed. The receiver needs to be able to authenticate M′.
 Given the received nblock message M, the intermediate node computes “new” blocks M′_{1}, . . . , M′_{n}. For each message block M_{n−i+1 }(starting from the end, i=1 to i=n), it computes the corresponding auxiliary and partial hashes
g _{i} =H(IV _{0} , M _{n−i+1}) (6)  Depending on whether the block will be forwarded or dropped, the intermediate node computes
M′ _{n−i+1} =M _{n−i+1}, if block M _{i }is forwarded, or g _{i}, if block M _{i }is dropped (7) 
 The above transmission requires buffering r packets to perform verification. In practice r will be quite small. For a SHA1 based scheme r=3 and for an MD5 based scheme, r=4.

 2.3 Verification
 The receiver can verify the signature by computing h_{m }from M′_{1}, . . . , M′_{n }as follows. First, for each message block M′_{n−i+1 }(starting from the end, i=1 to i=n), and depending on whether the received block is a “message block” or a “hash”, the receiver computes
g′ _{i} =H(h _{i−1} ,M′ _{n−i+1}), if M′ _{n−i+1 }is a “message block” M′ _{n−i+1}, if M′ _{n−i+1 }is a “hash” (8)  Finally, the receiver computes h_{m}:
$\begin{array}{cc}\begin{array}{c}{h}_{1}=H\text{\hspace{1em}}\left({\mathrm{IV}}_{0},{g}_{1}^{\prime},\dots \text{\hspace{1em}},{g}_{r}^{\prime}\right)\\ {h}_{2}=H\text{\hspace{1em}}\left({h}_{1},{g}_{r+1}^{\prime},\dots \text{\hspace{1em}},{g}_{2r}^{\prime}\right)\\ \vdots \\ {h}_{m}=H\text{\hspace{1em}}\left({h}_{m1},{g}_{r\text{\hspace{1em}}\lfloor \frac{n}{r}\rfloor +1},\dots \text{\hspace{1em}},{g}_{n}\right)\end{array}& \left(9\right)\end{array}$  The receiver can then verify the signature on h_{m }as normal using the verification algorithm v.
 To perform online verification, the receiver needs to be able to compute the intermediate hash h_{i}. To do so, the receiver needs to buffer r blocks so it can compute the appropriate g values. The online verification of this scheme is analogous to that of the first embodiment.
 2.4 Security
 Similarly to the first embodiment, so long as the signature scheme is not easily susceptible to forgery and the hash function is not easily susceptible to collisions, the scheme of the second embodiment is secure.
 2.5 Performance
 Similarly to the first embodiment, when the intermediary removes blocks, it only needs to compute the hash of the block being removed.
 It takes less time for the subsequence scheme of the second embodiment to both compute and verify the signature compared to the subsequence scheme of the first embodiment, since only one secondlayer hash is performed for every r first layer hashes. If r is chosen carefully (for example, setting r=3 for SHA1 or r=4 for MD5), then each secondlayer hash only requires a single call to the compression function. So, in the second embodiment, only
$\lceil \frac{n}{r}\rceil $
compression function calls are made in the second layer compared to the n calls in the first embodiment.  In addition to the advantages of the first embodiment, the receiver of the second embodiment can verify the authentication information after receiving every r blocks. In practice, r will be fairly small—on the order of 2 or 3, thus reducing the number of the second layer hashes.
 3. Simulcast Authentication: the Multiplex Scheme
 Now, assume the original sender S transmits k different streams M^{(1)}, M^{(2)}, . . . , M^{(k) }simultaneously. Each stream consists of n blocks of length b, M^{(j)}=M_{1} ^{(j)}, . . . , M^{n} ^{(j)}. The scheme of the third embodiment allows the intermediate node not only to select one stream and retransmit it in an authenticated fashion, but also to “switch” to some other stream adaptively (at any point during block transmission). Of course, the receiver should be able to authenticate the resulting stream.
 3.1 Signing

FIG. 9 shows a basic linear simulcast authentication scheme according to one embodiment of the present invention. Given a message M, signature generation follows the same approach as in the first and second embodiments, i.e., reverse iterated hash, but computing partial hashes of every block in each stream.  Given messages M^{(1)}, M^{(2)}, . . . , M^{(k)}, where M^{(j)}=M_{1} ^{(j)}, M_{2} ^{(j)}, . . . , M_{n} ^{(j)}, the scheme of the third embodiment of the present invention generates the partial hash computations h_{1}, . . . , h_{n }as follows:
$\begin{array}{cc}\begin{array}{c}{d}_{1}^{\left(1\right)}=H\text{\hspace{1em}}\left({M}_{n}^{\left(1\right)}\right)\\ {d}_{1}^{\left(2\right)}=H\text{\hspace{1em}}\left({M}_{n}^{\left(2\right)}\right)\\ \vdots \\ {d}_{1}^{\left(k\right)}=H\text{\hspace{1em}}\left({M}_{n}^{\left(k\right)}\right)\\ {h}_{1}=H\text{\hspace{1em}}\left({h}_{0},{d}_{1}^{\left(1\right)},\dots \text{\hspace{1em}},{d}_{1}^{\left(k\right)}\right)\\ \vdots \\ {d}_{n}^{\left(1\right)}=H\text{\hspace{1em}}\left({M}_{1}^{\left(1\right)}\right)\\ {d}_{n}^{\left(2\right)}=H\text{\hspace{1em}}\left({M}_{1}^{\left(2\right)}\right)\\ \vdots \\ {d}_{n}^{\left(k\right)}=H\text{\hspace{1em}}\left({M}_{1}^{\left(k\right)}\right)\\ {h}_{n}=H\text{\hspace{1em}}\left({h}_{n1},{d}_{n}^{\left(1\right)},\dots \text{\hspace{1em}},{d}_{n}^{\left(k\right)}\right)\end{array}& \left(10\right)\end{array}$ .
d _{n} ^{(1)} =H(M _{1} ^{(1)})
d _{n} ^{(2)} =H(M _{1} ^{(2)})
.
.
.
d _{n} ^{(k)} =H(M _{1} ^{(k)})
h _{n} =H(h _{n−1} ,d _{n} ^{(1)} , . . . ,d _{n} ^{(k)}) (10)  The initial sender transmits σ_{Sk}(h_{n}) and then sends M^{(1)}, . . . , M^{(k) }simultaneously. In practice, the message blocks of the different streams will be interleaved in the transmission.
 3.2 Signature Update
 Suppose an intermediate node wants to select a possibly different stream (message) for each message block received. For instance, if each message encodes a video stream of different quality, the intermediate node may want to select a lower or higher quality depending on network congestion. It generates a “resulting message” M′, comprising “chunks” (consecutive message blocks) of the different streams. The intermediate node may pick a single stream (message) at each moment. It should be understood that the present invention allows for the possibility of layered streams. The receiver needs to be able to authenticate M′.
 Given the received nblock messages M^{(1)}, . . . , M^{(k)}, the intermediate node computes “new” blocks M′_{1}, . . . , M′_{n}. For each set of message blocks M_{n−i+1} ^{(1)}, . . . , M_{n−i+1} ^{(k)}, (starting from the end, i=1 to i=n), it computes the partial hashes
$\begin{array}{cc}\begin{array}{c}{d}_{i}^{\left(1\right)}=H\text{\hspace{1em}}\left({M}_{ni+1}^{\left(1\right)}\right)\\ {d}_{i}^{\left(2\right)}=H\text{\hspace{1em}}\left({M}_{ni+1}^{\left(2\right)}\right)\\ \vdots \\ {d}_{i}^{\left(k\right)}=H\text{\hspace{1em}}\left({M}_{ni+1}^{\left(k\right)}\right)\\ {h}_{i}=H\text{\hspace{1em}}\left({h}_{i1},{d}_{i}^{\left(1\right)},\dots \text{\hspace{1em}},{d}_{i}^{\left(k\right)}\right)\end{array}& \left(11\right)\end{array}$  Then if stream l is chosen, 1≦l≦k, it computes
M′ _{n−i+1}=(d _{i} ^{(1)} , . . . ,d _{i} ^{l−1)} ,M _{n−i+1} ^{(l)} ,d _{i} ^{(l+1)} , . . . ,d _{i} ^{(k)}). (12) 

 The receiver can verify the signature by computing h_{n}, from M′_{1}, . . . , M′_{k }and h_{0}=IV_{0}. For each message block M′_{n−i+1 }(starting from the end, i=1 to i=n) if M′_{n−i+1 }is of the form
M′ _{n−i+1}=(d _{i} ^{(1)} , . . . ,d _{i} ^{(l−1)} ,M _{n−i+1} ^{(l)} ,d _{i} ^{(l+1)} , . . . ,d _{i} ^{(k)})  then, the receiver computes
d _{i} ^{(k)} =H(M _{n−i+1} ^{(k)})
h _{i} =H(h _{i−1} ,d _{i} ^{(1)} , . . . ,d _{i} ^{(l−1)} ,d _{i} ,d _{i} ^{(l+1)} , . . . ,d _{i} ^{(k)}) (14)  The receiver can then verify the signature on h_{n }as normal using the verification algorithm v.
 The alternative online verification procedure is straightforward. The receiver computes the partial hash h_{n }from (M′_{1}, h_{n−1}) using relation (14) and then it verifies the signature on the partial hash h_{n}. Afterwards, for i=2, . . . , n, it computes the partial hash h_{i }from (M′_{i}, h_{n−i}) using (14) and verifies the so computed hash matches the hash value received in iteration i−1.
 3.4 Performance
 In addition to the advantages of the scheme of the first embodiment, the hash step of the scheme of the third embodiment can be iterated using a compression function with either the linear chaining scheme or a Merkle scheme.
 By using a Merkle treelike construction to hash down each sequence of blocks M_{i} ^{(1)}, . . . , M_{i} ^{(k)}, bandwidth can be saved at the cost of more intensive computation (by the intermediate node).
 4. Tree Scheme for Subsequence Authentication
 The fourth embodiment of the present invention is a scheme for authenticating subsequences using Merkle Trees. Like the linear subsequence authentication scheme, the treebased scheme allows stream authentication even when arbitrary blocks from the message are removed. As long as the blocks sent by the intermediate node are a proper subsequence of the original message, the receiver can authenticate the stream. By exploiting certain aspects of the tree structure, the tree scheme is more efficient with respect to bandwidth than the linear scheme.
 4.1 Signing

FIG. 10 illustrates a treebased subsequence authentication scheme according to one embodiment of the present invention. Given a message M=M_{1}M_{2 }. . . M_{n}, the scheme of the fourth embodiment generates a Merkle tree shown inFIG. 6 . If v denotes the root of the tree and x denotes the value associated with the root, then the initial sender transmits (M, σ_{Sk}(x)).  4.2 Signature Update
 If an intermediary wants to strip off k arbitrarily located message blocks, the intermediary generates a resulting “message” M′, identical to M, but with k blocks removed. The receiver needs to be able to authenticate M′. Let d_{1}, . . . , d_{k }denote the indices of the blocks that will be dropped and let s_{1}, . . . , s_{n−k }denote the blocks that will stay. Given the received nblock message M, the intermediate node computes the corresponding authentication information as follows.
 1) For all blocks M_{d} _{ 1 }, . . . , M_{d} _{ k }that are to be dropped, the intermediary first determines the set of vertices corresponding to leaves l_{d} _{ 1 }, . . . l_{d} _{ k }in the Merkle tree associated with these blocks.
 2) If any pair of vertices are siblings in the Merkle tree, the intermediary replaces these two vertices both with their parent.
 3) The intermediary keeps repeating the above process until no two vertices in the set are siblings.
 4) The intermediary takes this set of vertices, and computes the Merkle tree values x_{1}, . . . , x_{r }associated with them. The intermediary can easily perform this step since the
 fifth and sixth switches (405, 406) connected between the first terminal

 Similarly to other embodiments of the present invention, applying standard encoding to the block contents facilitates distinguishing between “message blocks” and “hashes”.
 4.3 Verification
 The receiver verifies the signature by computing the value of the root of the Merkle tree, using the following algorithm:
 1) For every actual message block M_{s} _{ i }received, compute the value y_{i}=H(IV_{0},M_{s} _{ i }).
 2) Consider the set of all hashes y_{1}, . . . , y_{n−k}, x_{1}, . . . , x_{r}. Each of these corresponds to values of vertices in a Merkle tree.
 3) For each pair of values, if they correspond to vertices who are siblings, then replace the pair with their hash (which corresponds to the parent node).
 4) Repeat the above step until only one value remains—this value is the root.
 If one has all the initial message blocks, then the above algorithm constitutes the standard algorithm for computing the root of a Merkle tree. Whenever the receiver receives some hashes x_{1}, . . . , x_{r}, these come from the intermediary running the same algorithm on the subset of missing blocks. Therefore, the intermediary and receiver have together run the algorithm on all n blocks which yield the value of the Merkle root. This is why the above computation yields the Merkle root.
 With the value of the Merkle root, the receiver can verify the signature it receives.
 4.4 Security
 The Merkle hash construction is collision resistant so long as the underlying hash function H is collision resistant. In particular, if one finds a collision in the Merkle tree, then at some point there is a collision at an internal node, which means one can find a collision on the hash function H. If an adversary can come up with a nonsubsequence forgery (that is, come up with a message/signature pair that is not obtained by merely taking a subsequence of the original message), then one can demonstrate either a collision in the hash function or a forgery on the underlying signature scheme. Therefore, as long as the signature scheme is not easily susceptible to forgery and the hash function is not easily susceptible to collisions, the scheme of the fourth embodiment is secure.
 4.5 Performance
 When the intermediary removes blocks, it needs to provide the receiver with a sufficient number of internal hashes to compute the Merkle root of the tree without those message blocks. The intermediary will require k hashes for each of the blocks to be dropped and then at most k−1 hashes when replacing pairs of hashes with a single hash (since a single hash results in replacing two values with a single one, thereby reducing the net number by one). The total computation is therefore at most 2k−1 hashes. The total hashes computed by a single common switch (the number of switching elements is 12) to be shared.
 When the receiver receives the stream, it needs to compute the root. If it has all the message blocks, this would require 2n−1 hashes−n to initially hash each block, and then n−1 additional hashes when replacing pairs of hash values with a single hash (since a single function computation results in replacing two values with a single one, and at the end only one value is remaining). However, t of these hashes are computed by the intermediary. Therefore the receiver only has to compute 2n−1−t hashes.
 The total work in this scheme between the intermediary and the receiver is at most 2n−1 hashes. In the previous linear schemes 2n hashes were required.
 In terms of bandwidth, the tree based scheme may be much more efficient. Only r≦k hashes are finally sent. In the best case, if all k blocks to be dropped entirely constitute all leaves of a subtree in the Merkle tree, then only the single value corresponding to the root of this subtree is sent, that is r=1. In the worst case, if no pair of blocks are siblings, then the bandwidth requirements are the exact same as in the linear case, and k hash values need to be sent.
 5. Tree Scheme for Simulcast Authentication
 The fifth embodiment of the present invention is a treebased scheme for authenticating multiple parallel streams in which one data block is selected from one stream at each step of the transmission. As in the linear multiplex setting of the third embodiment, it is assumed that the original sender S transmits k different streams M^{(1)}, M^{(2)}, . . . , M^{(k) }simultaneously. Each stream consists of n blocks of length b, M^{(j)}=M_{I} ^{(j)}, . . . , M^{n} ^{(j)}. This scheme allows the intermediate node not only to select one stream and retransmit it in an authenticated fashion, but also to “switch” to some other stream adaptively (at any point during block transmission). Of course, the receiver is able to authenticate the resulting stream. As in the treebased scheme for subsequence authentication of the fourth embodiment, the scheme of the fifth embodiment exploits certain aspects of the tree structure, so as to be more efficient with respect to bandwidth than the analogous linear scheme. On the other hand, like the tree construct of the fourth embodiment, the scheme of the fifth embodiment does not readily lend itself to online verification. Instead, the receiver has to wait for all packets before it can verify. In practice, the delay can be reduced by splitting the stream into segments of reasonable size and authenticating each segment separately.
 5.1 Signing
 Given k different streams M^{(1)}, M^{(2)}, . . . , M^{(k)}, the signature generation of the scheme of the fifth embodiment works as follows.
 1) The signer first generates a separate Merkle tree for each stream. Let v^{(1)}, . . . , v^{(k) }denote the k roots of the tree, and let x^{(1)}, . . . , x^{(k) }denote the respective values associated with these roots.
 2) The signer then computes x=H(IV, x^{(1)}, . . . , x^{(k)}). Here the hash function H can be computed using a Merkle tree construction as well.
 3) Finally, the signer transmits (M, σ_{Sk}(x)).
 5.2 Signature Update
 Now, suppose an intermediate node wants to select a possibly different stream (message) for each message block received. For instance, if each message encodes a video stream of different quality, the intermediate node may want to select a lower or higher quality depending on network congestion. It generates a resulting “message” M′, comprising “chunks” (consecutive message blocks) of the different streams. The receiver needs to be able to authenticate M′.
 If the receiver can accurately compute each of the x_{i }values, then it can verify the signature. Therefore, the intermediary simply has to provide the user with the information necessary to compute these values. By treating each Merkle tree separately, the intermediary can compute the set of required values as it did in the Merkle scheme of the fourth embodiment. The intermediary transmits these values to the receiver which can then compute the x_{i }values and inturn verify the authentication information.
 Specifically, for each i with 1≦i≦k, let ks(i) denote the number of blocks that will actually be sent from stream M^{(i)}. For the stream M^{(i)}, let s_{1} ^{(i)}, . . . , s_{ks(i)} ^{(i) }denote the indices of the blocks that will be included. Let M′^{(i) }denote these blocks:
$\begin{array}{cc}{M}^{\prime}\left(i\right)={M}_{{s}_{1}\left(i\right)}^{\left(i\right)}\dots \text{\hspace{1em}}{M}_{{s}_{\mathrm{ks}\left(i\right)}^{\left(i\right)}}^{\left(i\right)}& \left(16\right)\end{array}$  As to the indices of blocks that are to be dropped, for each i with 1≦i≦k, let kd(i) denote the number of blocks that will actually be dropped from stream M^{(i)}. For the stream M^{(i)}, let d_{1} ^{(i)}, . . . , d_{kd(i)} ^{(i) }denote the indices of the blocks that will be dropped.
 As in the tree scheme of the fourth embodiment, for each stream M^{(i) }the intermediary computes the values necessary for the receiver to verify as follows:
 1) For all blocks
${M}_{{d}_{1}^{\left(i\right)}}^{\left(i\right)},\dots \text{\hspace{1em}},{M}_{{d}_{k}^{\left(i\right)}}^{\left(i\right)}$
that are to be dropped, the intermediary first determines the set of vertices corresponding to leaves${l}_{{d}_{1}^{\left(i\right)}},\dots \text{\hspace{1em}},{l}_{{d}_{\mathrm{kd}\left(i\right)}^{\left(i\right)}}$
in the Merkle tree associated with these blocks.  2) Now, if any pair of vertices are siblings in the Merkle tree, the intermediary replaces these two vertices both with their parent, i.e., the hash of concatenation of the values associated with the siblings.
 3) The intermediary keeps repeating the above process until no two vertices in the set are siblings.
 4) The intermediary takes this set of vertices, and computes the Merkle tree values X^{(i)}=x_{1} ^{(i)}, . . . , x_{r} ^{(i) }associated with them. The intermediary can easily perform this step since the cryptographic hash function is globally computable.

 The stream is sent in the proper order, that is, blocks from each of the M′^{(i) }may be interleaved so that the receiver can view the stream. Some standard encoding is applied to the block contents so the receiver can distinguish between message blocks versus hash values.
 5.3 Verification
 The receiver verifies the signature by first computing the values of the roots of each of the Merkle trees—after that it hashes these values and verifies the signature. It achieves this goal using the following algorithm which is run for each i:
 1) First, for every actual message block M_{sj} ^{(i) }received, the receiver computes the value y_{j} ^{(i)}=H(IV_{0},M_{sj} ^{(i)}).
 2) Consider the set of all hashes computed above in the previous step as well the hash values contained in sets X^{(1)}, . . . , X^{(k) }received in the transmissions.
 3) For each pair of values, if the pair corresponds to vertices who are siblings, then replace the pair with their hash (which corresponds to the parent node in the Merkle tree).
 4) Repeat the above step until only one value remains—this value is the root x^{(i)}.
 If one has all the initial message blocks, then the above algorithm constitutes the standard algorithm for computing the root of a Merkle tree. Whenever the receiver receives some hashes x_{1} ^{(i)}, . . . , x_{r} ^{(i)}, these come from the intermediary running the same algorithm on the subset of missing blocks. Therefore, the intermediary and receiver have together run the algorithm on all n blocks which yield the value of the Merkle root. This is why the above computation yields the Merkle root.
 With the values of the Merkle roots, x^{(1)}, . . . , x^{(k)}, the receiver can compute x=H(IV, x^{(1)}, . . . , x^{(k)}) and verify the signature it receives.

FIG. 11 illustrates the signing and verification of the fifth embodiment of the invention, an example with four streams and four message blocks. As shown, each of the four streams M^{(1)}, M^{(2)}, M^{(3)}, M^{(4) }consists of four blocks. The black leaves denote the message blocks that are actually sent. The remaining ones are dropped. The shaded vertices represent the cover; that is, the values corresponding to these vertices are sent to the receiver. The roots of the four Merkle trees are x^{(1)}, x^{(2)}, x^{(3)}, and x^{(4) }respectively. The final root value x is computed by hashing the Merkle roots x^{(1)}, x^{(2)}, x^{(3)}, x^{(4)}. This hash can be also be performed in a Merklelike fashion. Finally, the value x is actually signed. In this scheme only six hash values are sent to the receiver. In the linear simulcast scheme, twelve hashes (three per each block transmitted) would have been transmitted. Thus, savings is achieved whenever dropped blocks are clustered. For example, inFIG. 11 , all blocks in the stream M^{(4) }are dropped. As a result, one only needs to send the root x^{(4) }of the associated Merkle tree.  Also, because the Merkle roots are themselves hashed in a Merklelike construction, there is room for further optimization. In particular, suppose that all blocks are dropped for two entire subtrees whose Merkle roots are siblings in the even larger tree. Then, instead of sending the two Merkle roots, their hash could be sent.
 5.4 Security
 Similarly to the fourth embodiment, the fifth embodiment is secure as long as the signature scheme is not easily susceptible to forgery, and the hash function is not easily susceptible to collisions. Thus the invention presented above is secure.
 5.5 Performance
 The performance of the fifth embodiment can be analyzed by extending the analysis for the treebased subsequence scheme and the linear simulcast scheme.
 In all embodiments above, a hash function with a specific payload size and a specific IV is used. The chaining constructions tend to take some existing output and use that as the IV of the next block. In a further embodiment, instead of loading the current output as an IV, the current output can be concatenated to the next payload.
 The linear and tree schemes of the present invention can be combined to obtain hybrid solutions, giving rise to useful tradeoffs. In a further embodiment, a scheme starts by splitting each stream M^{(i) }into segments of length b blocks. Then, a tree scheme is applied on the first segment of all streams to compute the Merkle root x_{1}, then the root on the second segment, and so on, until all segments are processed. In this way, Merkle roots x_{1}, . . . , x_{└n/b┘} are obtained. Instead of signing each one of these roots, as in the tree schemes described above, the roots are combined using the linear scheme. Hence, if the receiver can buffer b blocks, then verification can be done “online”. Moreover, the communication overhead is decreased compared to the plain linear scheme since for each segment of b blocks, the number of transmitted hashes may be much less than the number of dropped blocks (although equal on the worst case). A similar approach can be taken for subsequence authentication. This hybrid approach allows trading buffer space for communication overhead.
 In a further embodiment, a linear scheme is applied to each stream, and then a Merkle tree is computed on the results.
 Although the embodiments described above use binary Merkle trees, the constructions can be applied to general trees. It may be more advantageous to group certain blocks together if they have similar behavior; i.e., they either all will be dropped or all will be kept.
 If there are correlations among blocks, then it makes sense to cluster these blocks together in the treebased schemes. For example, if a group of blocks will either all be dropped or all be kept, it is advantageous to have these blocks constitute all the leaves of a subtree. Then, if the packets are dropped, only the root of the subtree must be sent.
 In addition, the Merkle tree construction could be optimized. In one embodiment, if one of the streams will more likely be used than the others, it is advantageous to use a lopsided Merkle tree in which the priority stream is close to the root (e.g., perhaps right below it). In conjunction with the hybrid scheme mentioned previously, the streams are prioritized, so that the high priority streams are closer to the final value in the chain. This ordering particularly makes sense when layered streams are used. In such cases, the voltage difference between V(T1) and V(,, 2) to 2:1.
 There are blocks that should never be dropped, such as, an I frame in an MPEG stream, or the base layer in a scalably coded stream. The signer can avoid directly computing the initial firstlayer hash on a block that will not be dropped. In the linear schemes, there are two hash layers. If a block will not be dropped, then there is no need to compute the hash in the first layer; instead only the second layer needs to be computed.
 The schemes of the present invention can be interpreted as having two phases. In the first phase, it finds a convenient way to hash each data block. In the second phase, it signs the hashes. The reason for doing so is that if a block is dropped, it is not necessary to retransmit it in its entirety. Instead, only the hash computed in the first phase is transmitted. This information is sufficient to allow the receiver to verify, since the signature can be viewed as being performed on the hashes. dividing the voltage difference between V(T1) and V(,, 2) to 2:1. In
FIG. 6 , the is, the sender drops particular blocks on purpose. Of course, in many practical applications, one may have to deal with uncontrolled loss situations. These situations may occur, for example, if the transport protocol is not reliable such as the case with UDP, or if the environment is subject to lossy behavior such as is the case with wireless networks. The present invention can be used to deal with the uncontrolled loss by replicating the hashes that would be sent if the packet were dropped.  By applying Forward Error Correction (FEC) techniques such as Erasure Codes to the hashes of the present invention, it is possible to deal with the uncontrolled loss situation without having to replicate. This approach might be especially useful in a multicast setting where different receivers have lost different packets but can be provided with identical errorcorrecting information. One consideration of this approach is that the receiver must perform a decoding step so may have to compromise the ability to verify authentication information in an online manner.
 Moreover, schemes of the present invention involve an intermediary which can adaptively choose the amount of forward error correction to the authentication information (i.e., hash outputs). In other words, rather than having a source estimate how much loss will occur and include sufficient authentication forward error correction information to accommodate that, the source can choose not to include authentication forward error correction information at all, and instead allow an intermediary to include the authentication forward error correction information dynamically to further increase the probability that the stream can be authenticated.
 The intermediary becomes an integral part of a scheme which considers both uncontrolled losses handled through forward error correction as well as adaptive and intelligent controlled losses. For example, in the Merkle tree constructions, it may suffice for the recipient to recover intermediate nodes (as opposed to just leaf nodes). In such a case, the intermediary can choose to supply forward error correction information to allow recovery of the (possibly interior) nodes necessary to authenticate, thus requiring possibly less forward error correction information.
 If the intermediary is sending different versions of the same stream to multiple receivers, because, for example, each has a different resource constraint with respect to the quality they view, the intermediary can recycle the work effort. In particular, the between the terminals T1, T2 and adapted to receive as input data bit signals D1B, most one full set of firstlayer hashes.
 Along these lines, work can be recycled between the source and the intermediary. That is, the source can provide the intermediary with any necessary hash computations for assisting with authentication. Then, the intermediary is not required to perform any work of a cryptographic nature. Instead, it can choose which blocks to drop and select the corresponding authentication information to be transmitted.
 Another application of the present invention is insertion and selection of advertisements in a stream. The intermediary or some other party provides advertisements or a hash of advertisements, for example hashed using a Merkle tree, to the source. The source then includes the Merkle hash in its stream as a placeholder, allowing the intermediary to choose which advertisement it would like to use. Of course, this concept is not necessarily limited to advertisers.
 Although the focus of the present invention is on authenticating information, the above scheme can also be used in conjunction with an encryption scheme provided that the scheme is designed to permit the recipient to decrypt a given block without requiring the decryption of or presence of many other blocks. Two block cipher encryption modes facilitate this approach. One is countermode encryption and the other is electronic code book (ECB) encryption. Alternatively, it is possible to use a stream cipher, though a caveat is that the receiver may need to perform work that is proportional to the size of the original stream as opposed to the portion of it that he receives. One may be able to use chaining or feedback modes (cipher block chaining (CBC), output feed back (OFB), etc) provided that the receiver receives any intermediate information to decrypt. Such information may include intermediate IVs or actual ciphertext blocks. Yet another approach is to mix the modes, i.e., for large segments which will not be dropped, a chaining or feedback mode can be used; whereas for other blocks, a counter mode or ECB mode can be used. For example, in an MPEG stream, Iframes are never dropped intentionally, so they can be treated differently and encrypted using CBC mode. A similar remark applies to the base layer of any scalable coding scheme.
 While the invention has been described in detail above with respect to various embodiments, the ordinarily skilled artisan will appreciate that variations of these embodiments are possible without departing from the scope and spirit of the invention. Therefore, the invention should be considered as limited only by the scope of the appended claims.
Claims (82)
Priority Applications (3)
Application Number  Priority Date  Filing Date  Title 

US49578703P true  20030815  20030815  
US10/543,640 US20060136728A1 (en)  20030815  20040804  Method and apparatus for authentication of data streams with adaptively controlled losses 
PCT/US2004/025513 WO2005017809A2 (en)  20030815  20040804  Method and apparatus for authentication of data streams with adaptively controlled losses 
Applications Claiming Priority (3)
Application Number  Priority Date  Filing Date  Title 

US10/543,640 US20060136728A1 (en)  20030815  20040804  Method and apparatus for authentication of data streams with adaptively controlled losses 
US12/560,963 US20100005310A1 (en)  20030815  20090916  Method and apparatus for authenication of data streams with adaptively controlled losses 
US12/560,959 US8256015B2 (en)  20030815  20090916  Method and apparatus for authentication of data streams with adaptively controlled losses 
Related Child Applications (2)
Application Number  Title  Priority Date  Filing Date 

US12/560,963 Division US20100005310A1 (en)  20030815  20090916  Method and apparatus for authenication of data streams with adaptively controlled losses 
US12/560,959 Division US8256015B2 (en)  20030815  20090916  Method and apparatus for authentication of data streams with adaptively controlled losses 
Publications (1)
Publication Number  Publication Date 

US20060136728A1 true US20060136728A1 (en)  20060622 
Family
ID=34193346
Family Applications (3)
Application Number  Title  Priority Date  Filing Date 

US10/543,640 Abandoned US20060136728A1 (en)  20030815  20040804  Method and apparatus for authentication of data streams with adaptively controlled losses 
US12/560,959 Expired  Fee Related US8256015B2 (en)  20030815  20090916  Method and apparatus for authentication of data streams with adaptively controlled losses 
US12/560,963 Abandoned US20100005310A1 (en)  20030815  20090916  Method and apparatus for authenication of data streams with adaptively controlled losses 
Family Applications After (2)
Application Number  Title  Priority Date  Filing Date 

US12/560,959 Expired  Fee Related US8256015B2 (en)  20030815  20090916  Method and apparatus for authentication of data streams with adaptively controlled losses 
US12/560,963 Abandoned US20100005310A1 (en)  20030815  20090916  Method and apparatus for authenication of data streams with adaptively controlled losses 
Country Status (3)
Country  Link 

US (3)  US20060136728A1 (en) 
JP (1)  JP4809766B2 (en) 
WO (1)  WO2005017809A2 (en) 
Cited By (50)
Publication number  Priority date  Publication date  Assignee  Title 

US20030145060A1 (en) *  20011018  20030731  Martin Anthony G.  Presentation of information to endusers 
US20070005425A1 (en) *  20050628  20070104  Claria Corporation  Method and system for predicting consumer behavior 
US20070022293A1 (en) *  20050725  20070125  Canon Kabushiki Kaisha  Information processing apparatus and method 
US20070038855A1 (en) *  20050812  20070215  Research In Motion Limited  System and method for authenticating streamed data 
US20070106908A1 (en) *  20051104  20070510  Kunihiko Miyazaki  Electronic document authenticity guarantee method, and electronic document disclosure system 
US20080216151A1 (en) *  20061227  20080904  Kunihiko Miyazaki  Electronic data authenticity assurance method and program 
US20080256362A1 (en) *  20070122  20081016  Fujitsu Limited  Method and apparatus for digital signature authentication, and computer product 
US20080294903A1 (en) *  20070523  20081127  Kunihiko Miyazaki  Authenticity assurance system for spreadsheet data 
US20090019520A1 (en) *  20041029  20090115  International Business Machines Corporation  Systems and Methods for Efficiently Authenticating Multiple Objects Based on Access Patterns 
US20090034783A1 (en) *  20070804  20090205  International Business Machines Corporation  System and method for solving the birthday problem with watermarking 
US20090204818A1 (en) *  20080213  20090813  Samsung Electronics Co., Ltd.  Method and apparatus for generating and verifying electronic signature of software data, and computer readable recording medium thereof 
US20090210715A1 (en) *  20060801  20090820  Fujitsu Limited  Document verification apparatus, document verification method, and computer product 
US20090320130A1 (en) *  20080620  20091224  International Business Machines Corporation  Traitor detection for multilevel assignment 
US20090319227A1 (en) *  20080620  20091224  International Business Machines Corporation  Adaptive traitor tracing 
US20100040231A1 (en) *  20080815  20100218  International Business Machines Corporation  Security Classes in a Media Key Block 
US20100146040A1 (en) *  20081210  20100610  At&T Corp.  System and Method for Content Validation 
US20100212017A1 (en) *  20090218  20100819  International Business Machines Corporation  System and method for efficient trust preservation in data stores 
US20100251067A1 (en) *  20090331  20100930  Qualcomm Incorporated  Systems and methods for protecting a multipart broadcast control message 
US8073866B2 (en)  20050317  20111206  Claria Innovations, Llc  Method for providing content to an internet user based on the user's demonstrated content preferences 
US8078602B2 (en)  20041217  20111213  Claria Innovations, Llc  Search engine for a computer network 
US8086697B2 (en)  20050628  20111227  Claria Innovations, Llc  Techniques for displaying impressions in documents delivered over a computer network 
US8132073B1 (en) *  20090630  20120306  Emc Corporation  Distributed storage system with enhanced security 
US8255413B2 (en)  20040819  20120828  Carhamm Ltd., Llc  Method and apparatus for responding to request for informationpersonalization 
US8316003B2 (en)  20021105  20121120  Carhamm Ltd., Llc  Updating content of presentation vehicle in a computer network 
US20120303990A1 (en) *  20110526  20121129  Google Inc.  Postponing suspend 
US8381062B1 (en) *  20070503  20130219  Emc Corporation  Proof of retrievability for archived files 
US8571209B2 (en)  20090119  20131029  International Business Machines  Recording keys in a broadcastencryptionbased system 
RU2509424C2 (en) *  20090807  20140310  Долби Интернешнл Аб  Data stream authentication 
US8689238B2 (en)  20000518  20140401  Carhamm Ltd., Llc  Techniques for displaying impressions in documents delivered over a computer network 
US20140173682A1 (en) *  20080919  20140619  Interdigital Patent Holdings, Inc.  Authentication for secure wireless communication 
US8832466B1 (en) *  20060127  20140909  Trustwave Holdings, Inc.  Methods for augmentation and interpretation of data objects 
US20140365026A1 (en) *  20130611  20141211  Kabushiki Kaisha Toshiba  Signature generating apparatus, signature generating method, computer program product, and electrical power consumption calculation system 
US9322974B1 (en)  20100715  20160426  Proxense, Llc.  Proximitybased system for object tracking 
US20160204942A1 (en) *  20130823  20160714  Nec Europe Ltd.  Method and system for authenticating a data stream 
US9495446B2 (en)  20041220  20161115  Gula Consulting Limited Liability Company  Method and device for publishing crossnetwork user behavioral data 
US20160357544A1 (en) *  20150605  20161208  Apple Inc.  On demand resources 
US9536016B2 (en) *  20130116  20170103  Google Inc.  Ondisk multimap 
US20170054619A1 (en) *  20150821  20170223  Barefoot Networks, Inc.  Fast detection and identification of lost packets 
US9621630B2 (en)  20140224  20170411  Fujitsu Limited  Distribution method, distribution apparatus, and terminal apparatus 
US9679276B1 (en) *  20160126  20170613  Stampery, Inc.  Systems and methods for using a block chain to certify the existence, integrity, and/or ownership of a file or communication 
US9960920B2 (en)  20160126  20180501  Stampery Inc.  Systems and methods for certification of data units and/or certification verification 
US10333696B2 (en)  20150112  20190625  XPrime, Inc.  Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency 
US10412069B2 (en)  20150119  20190910  Mitsubishi Electric Corporation  Packet transmitting apparatus, packet receiving apparatus, and computer readable medium 
US10698989B2 (en)  20041220  20200630  Proxense, Llc  Biometric personal data key (PDK) authentication 
US10764044B1 (en)  20060505  20200901  Proxense, Llc  Personal digital key initialization and registration for secure transactions 
US10769939B2 (en)  20071109  20200908  Proxense, Llc  Proximitysensor supporting multiple application services 
US10909229B2 (en)  20130510  20210202  Proxense, Llc  Secure element as a digital pocket 
US10943471B1 (en)  20061113  20210309  Proxense, Llc  Biometric authentication using proximity and secure information on a user device 
US10971251B1 (en)  20080214  20210406  Proxense, Llc  Proximitybased healthcare management system with automatic access to private information 
US11069211B1 (en)  20190114  20210720  Proxense, Llc  Proximitybased system for object tracking and automatic application initialization 
Families Citing this family (22)
Publication number  Priority date  Publication date  Assignee  Title 

JP4809766B2 (en) *  20030815  20111109  株式会社エヌ・ティ・ティ・ドコモ  Data stream authentication method and apparatus adaptively controlling loss 
EP1944907A4 (en) *  20051104  20110831  Nec Corp  Message authentication device, message authentication method, message authentication program, and recording medium therefor 
CN101411120B (en) *  20060125  20121031  法国电信公司  Burnin system for multicast data transmission 
WO2007093946A1 (en) *  20060214  20070823  Koninklijke Philips Electronics N.V.  Improved method of content protection 
WO2007093925A1 (en) *  20060214  20070823  Koninklijke Philips Electronics N.V.  Improved method of content protection 
US8323087B2 (en)  20060918  20121204  Igt  Reduced power consumption wager gaming machine 
JP4584300B2 (en) *  20071219  20101117  富士通株式会社  Electronic signature program, computerreadable recording medium, electronic signature device, and electronic signature method 
GB0802585D0 (en) *  20080212  20080319  Mtld Top Level Domain Ltd  Determining a property of communication device 
EP2107711B1 (en) *  20080303  20101124  Fujitsu Ltd.  Method and apparatus for digital signature authentication, and computer product 
US8386785B2 (en)  20080618  20130226  Igt  Gaming machine certificate creation and management 
US8595504B2 (en) *  20080812  20131126  Industrial Technology Research Institute  Light weight authentication and secret retrieval 
GB2465138B (en) *  20081010  20121010  Afilias Technologies Ltd  Transcoding web resources 
US20110246779A1 (en)  20081211  20111006  Isamu Teranishi  Zeroknowledge proof system, zeroknowledge proof device, zeroknowledge verification device, zeroknowledge proof method and program therefor 
US9141724B2 (en)  20100419  20150922  Afilias Technologies Limited  Transcoder hinting 
GB2481843A (en)  20100708  20120111  Mtld Top Level Domain Ltd  Web based method of generating user interfaces 
US8538938B2 (en) *  20101202  20130917  At&T Intellectual Property I, L.P.  Interactive proof to validate outsourced data stream processing 
GB2508343A (en) *  20121128  20140604  Ibm  Replacing a hash function if a second hash function is more effective 
US10200199B2 (en) *  20130805  20190205  Guardtime Holdings Limited  Strengthened entity identity for digital record signature infrastructure 
US20180262551A1 (en) *  20150921  20180913  Dolby Laboratories Licensing Corporation  Efficient delivery of customized content over intelligent network 
KR101977109B1 (en) *  20151117  20190828  (주)마크애니  Large simultaneous digital signature service system based on hash function and method thereof 
WO2019157227A1 (en) *  20180207  20190815  Safetraces, Inc.  Source and sanitation assurance testing of foodstuffs and sensitive applications 
CA3051762A1 (en)  20181213  20190418  Alibaba Group Holding Limited  Data isolation in a blockchain network 
Citations (5)
Publication number  Priority date  Publication date  Assignee  Title 

US6490627B1 (en) *  19961217  20021203  Oracle Corporation  Method and apparatus that provides a scalable media delivery system 
US20030126400A1 (en) *  20011227  20030703  Jacques Debiez  Data integrity check method using cumulative hash function 
US6886098B1 (en) *  19990813  20050426  Microsoft Corporation  Systems and methods for compression of key sets having multiple keys 
US6959384B1 (en) *  19991214  20051025  Intertrust Technologies Corporation  Systems and methods for authenticating and protecting the integrity of data streams and other data 
US6970602B1 (en) *  19981006  20051129  International Business Machines Corporation  Method and apparatus for transcoding multimedia using content analysis 
Family Cites Families (5)
Publication number  Priority date  Publication date  Assignee  Title 

US6065008A (en) *  19971001  20000516  Microsoft Corporation  System and method for secure font subset distribution 
JP3434251B2 (en) *  19991102  20030804  日本電信電話株式会社  Message recovery type signature system and program recording medium thereof 
US20030123546A1 (en) *  20011228  20030703  Emblaze Systems  Scalable multilevel video coding 
US7313814B2 (en) *  20030401  20071225  Microsoft Corporation  Scalable, error resilient DRM for scalable media 
JP4809766B2 (en) *  20030815  20111109  株式会社エヌ・ティ・ティ・ドコモ  Data stream authentication method and apparatus adaptively controlling loss 

2004
 20040804 JP JP2006523251A patent/JP4809766B2/en not_active Expired  Fee Related
 20040804 WO PCT/US2004/025513 patent/WO2005017809A2/en active Application Filing
 20040804 US US10/543,640 patent/US20060136728A1/en not_active Abandoned

2009
 20090916 US US12/560,959 patent/US8256015B2/en not_active Expired  Fee Related
 20090916 US US12/560,963 patent/US20100005310A1/en not_active Abandoned
Patent Citations (5)
Publication number  Priority date  Publication date  Assignee  Title 

US6490627B1 (en) *  19961217  20021203  Oracle Corporation  Method and apparatus that provides a scalable media delivery system 
US6970602B1 (en) *  19981006  20051129  International Business Machines Corporation  Method and apparatus for transcoding multimedia using content analysis 
US6886098B1 (en) *  19990813  20050426  Microsoft Corporation  Systems and methods for compression of key sets having multiple keys 
US6959384B1 (en) *  19991214  20051025  Intertrust Technologies Corporation  Systems and methods for authenticating and protecting the integrity of data streams and other data 
US20030126400A1 (en) *  20011227  20030703  Jacques Debiez  Data integrity check method using cumulative hash function 
Cited By (86)
Publication number  Priority date  Publication date  Assignee  Title 

US8689238B2 (en)  20000518  20140401  Carhamm Ltd., Llc  Techniques for displaying impressions in documents delivered over a computer network 
US20030145060A1 (en) *  20011018  20030731  Martin Anthony G.  Presentation of information to endusers 
US8521827B2 (en)  20011018  20130827  Carhamm Ltd., Llc  Presentation of information to endusers 
US8316003B2 (en)  20021105  20121120  Carhamm Ltd., Llc  Updating content of presentation vehicle in a computer network 
US8255413B2 (en)  20040819  20120828  Carhamm Ltd., Llc  Method and apparatus for responding to request for informationpersonalization 
US8127134B2 (en) *  20041029  20120228  International Business Machines Corporation  Systems and methods for efficiently authenticating multiple objects based on access patterns 
US20090019520A1 (en) *  20041029  20090115  International Business Machines Corporation  Systems and Methods for Efficiently Authenticating Multiple Objects Based on Access Patterns 
US8078602B2 (en)  20041217  20111213  Claria Innovations, Llc  Search engine for a computer network 
US9495446B2 (en)  20041220  20161115  Gula Consulting Limited Liability Company  Method and device for publishing crossnetwork user behavioral data 
US10698989B2 (en)  20041220  20200630  Proxense, Llc  Biometric personal data key (PDK) authentication 
US8073866B2 (en)  20050317  20111206  Claria Innovations, Llc  Method for providing content to an internet user based on the user's demonstrated content preferences 
US8086697B2 (en)  20050628  20111227  Claria Innovations, Llc  Techniques for displaying impressions in documents delivered over a computer network 
US20070005425A1 (en) *  20050628  20070104  Claria Corporation  Method and system for predicting consumer behavior 
US7958361B2 (en) *  20050725  20110607  Canon Kabushiki Kaisha  Information processing apparatus and method 
US20070022293A1 (en) *  20050725  20070125  Canon Kabushiki Kaisha  Information processing apparatus and method 
US8407468B2 (en)  20050812  20130326  Research In Motion Limited  System and method for authenticating streamed data 
US20070038855A1 (en) *  20050812  20070215  Research In Motion Limited  System and method for authenticating streamed data 
US8078867B2 (en) *  20050812  20111213  Research In Motion Limited  System and method for authenticating streamed data 
US7941667B2 (en) *  20051104  20110510  Hitachi, Ltd.  Electronic document authenticity guarantee method, and electronic document disclosure system 
US20070106908A1 (en) *  20051104  20070510  Kunihiko Miyazaki  Electronic document authenticity guarantee method, and electronic document disclosure system 
US20170207910A1 (en) *  20060127  20170720  Trustwave Holdings, Inc.  Methods for cryptographic delegation and enforcement of dynamic access to stored data 
US9992014B2 (en) *  20060127  20180605  Trustwave Holdings, Inc.  Methods for cryptographic delegation and enforcement of dynamic access to stored data 
US8832466B1 (en) *  20060127  20140909  Trustwave Holdings, Inc.  Methods for augmentation and interpretation of data objects 
US9559837B2 (en)  20060127  20170131  Trustwave Holdings, Inc.  Methods for cryptographic delegation and enforcement of dynamic access to stored data 
US10764044B1 (en)  20060505  20200901  Proxense, Llc  Personal digital key initialization and registration for secure transactions 
US20090210715A1 (en) *  20060801  20090820  Fujitsu Limited  Document verification apparatus, document verification method, and computer product 
US10943471B1 (en)  20061113  20210309  Proxense, Llc  Biometric authentication using proximity and secure information on a user device 
US20080216151A1 (en) *  20061227  20080904  Kunihiko Miyazaki  Electronic data authenticity assurance method and program 
US8108906B2 (en) *  20061227  20120131  Hitachi, Ltd.  Electronic data authenticity assurance method and program 
US20080256362A1 (en) *  20070122  20081016  Fujitsu Limited  Method and apparatus for digital signature authentication, and computer product 
US8037312B2 (en) *  20070122  20111011  Fujitsu Limited  Method and apparatus for digital signature authentication, and computer product 
US8381062B1 (en) *  20070503  20130219  Emc Corporation  Proof of retrievability for archived files 
US8984363B1 (en) *  20070503  20150317  Emc Corporation  Proof of retrievability for archived files 
US20080294903A1 (en) *  20070523  20081127  Kunihiko Miyazaki  Authenticity assurance system for spreadsheet data 
US20090034783A1 (en) *  20070804  20090205  International Business Machines Corporation  System and method for solving the birthday problem with watermarking 
US8023693B2 (en) *  20070804  20110920  International Business Machines Corporation  System and method for solving the “birthday problem” with watermarking 
US7885427B2 (en) *  20070804  20110208  International Business Machines Corporation  System and method for solving the “birthday” problem with watermarking 
US20090034785A1 (en) *  20070804  20090205  International Business Machines Corporation  System and Method for Solving the "Birthday Problem" with Watermarking 
US10769939B2 (en)  20071109  20200908  Proxense, Llc  Proximitysensor supporting multiple application services 
US20090204818A1 (en) *  20080213  20090813  Samsung Electronics Co., Ltd.  Method and apparatus for generating and verifying electronic signature of software data, and computer readable recording medium thereof 
US8806212B2 (en) *  20080213  20140812  Samsung Electronics Co., Ltd.  Method and apparatus for generating and verifying electronic signature of software data, and computer readable recording medium thereof 
US10971251B1 (en)  20080214  20210406  Proxense, Llc  Proximitybased healthcare management system with automatic access to private information 
US8122501B2 (en)  20080620  20120221  International Business Machines Corporation  Traitor detection for multilevel assignment 
US20090320130A1 (en) *  20080620  20091224  International Business Machines Corporation  Traitor detection for multilevel assignment 
US8108928B2 (en)  20080620  20120131  International Business Machines Corporation  Adaptive traitor tracing 
US20090319227A1 (en) *  20080620  20091224  International Business Machines Corporation  Adaptive traitor tracing 
US8422684B2 (en)  20080815  20130416  International Business Machines Corporation  Security classes in a media key block 
US20100040231A1 (en) *  20080815  20100218  International Business Machines Corporation  Security Classes in a Media Key Block 
US20140173682A1 (en) *  20080919  20140619  Interdigital Patent Holdings, Inc.  Authentication for secure wireless communication 
US9596599B2 (en) *  20080919  20170314  Interdigital Patent Holdings, Inc.  Authentication for secure wireless communication 
US8108544B2 (en)  20081210  20120131  At&T Intellectual Property I, Lp  System and method for content validation 
US10511893B2 (en)  20081210  20191217  At&T Intellectual Property I, L.P.  System and method for content validation 
US8812587B2 (en)  20081210  20140819  At&T Intellectual Property Ii, L.P.  System and method for content validation 
US20100146040A1 (en) *  20081210  20100610  At&T Corp.  System and Method for Content Validation 
US9602882B2 (en)  20081210  20170321  At&T Intellectual Property I, L.P.  System and method for content validation 
US8571209B2 (en)  20090119  20131029  International Business Machines  Recording keys in a broadcastencryptionbased system 
US20100212017A1 (en) *  20090218  20100819  International Business Machines Corporation  System and method for efficient trust preservation in data stores 
US8627184B2 (en)  20090331  20140107  Qualcomm Incorporated  Systems and methods for protecting a multipart broadcast control message 
WO2010117847A3 (en) *  20090331  20110317  Qualcomm Incorporated  Systems and methods for protecting a multipart broadcast control message 
CN102379124A (en) *  20090331  20120314  高通股份有限公司  Systems and methods for protecting a multipart broadcast control message 
US20100251067A1 (en) *  20090331  20100930  Qualcomm Incorporated  Systems and methods for protecting a multipart broadcast control message 
US8132073B1 (en) *  20090630  20120306  Emc Corporation  Distributed storage system with enhanced security 
RU2509424C2 (en) *  20090807  20140310  Долби Интернешнл Аб  Data stream authentication 
US8885818B2 (en)  20090807  20141111  Dolby International Ab  Authentication of data streams 
US9322974B1 (en)  20100715  20160426  Proxense, Llc.  Proximitybased system for object tracking 
US9450956B1 (en) *  20100715  20160920  Proxense, Llc  Proximitybased system for automatic application initialization 
US10313336B2 (en)  20100715  20190604  Proxense, Llc  Proximitybased system for object tracking 
US9116704B1 (en)  20110526  20150825  Google Inc.  Delaying the initiation of transitioning to a lower power mode by placing a computer system into an intermediate power mode between a normal power mode and the lower power mode 
US8671299B2 (en) *  20110526  20140311  Google Inc.  Delaying the initiation of transitioning to a lower power mode by placing a computer system into an intermediate power mode between a normal power mode and the lower power mode 
US20120303990A1 (en) *  20110526  20121129  Google Inc.  Postponing suspend 
US9536016B2 (en) *  20130116  20170103  Google Inc.  Ondisk multimap 
US10909229B2 (en)  20130510  20210202  Proxense, Llc  Secure element as a digital pocket 
US20140365026A1 (en) *  20130611  20141211  Kabushiki Kaisha Toshiba  Signature generating apparatus, signature generating method, computer program product, and electrical power consumption calculation system 
US10263783B2 (en) *  20130823  20190416  Nec Corporation  Method and system for authenticating a data stream 
US20160204942A1 (en) *  20130823  20160714  Nec Europe Ltd.  Method and system for authenticating a data stream 
US9621630B2 (en)  20140224  20170411  Fujitsu Limited  Distribution method, distribution apparatus, and terminal apparatus 
US10333696B2 (en)  20150112  20190625  XPrime, Inc.  Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency 
US10412069B2 (en)  20150119  20190910  Mitsubishi Electric Corporation  Packet transmitting apparatus, packet receiving apparatus, and computer readable medium 
US10447812B2 (en) *  20150605  20191015  Apple Inc.  On demand resources 
US20160357544A1 (en) *  20150605  20161208  Apple Inc.  On demand resources 
US10110454B2 (en)  20150821  20181023  Barefoot Networks, Inc.  Fast detection and identification of lost packets 
US20170054619A1 (en) *  20150821  20170223  Barefoot Networks, Inc.  Fast detection and identification of lost packets 
US10044583B2 (en) *  20150821  20180807  Barefoot Networks, Inc.  Fast detection and identification of lost packets 
US9960920B2 (en)  20160126  20180501  Stampery Inc.  Systems and methods for certification of data units and/or certification verification 
US9679276B1 (en) *  20160126  20170613  Stampery, Inc.  Systems and methods for using a block chain to certify the existence, integrity, and/or ownership of a file or communication 
US11069211B1 (en)  20190114  20210720  Proxense, Llc  Proximitybased system for object tracking and automatic application initialization 
Also Published As
Publication number  Publication date 

JP2007503134A (en)  20070215 
WO2005017809A2 (en)  20050224 
US20100005310A1 (en)  20100107 
WO2005017809A3 (en)  20050922 
JP4809766B2 (en)  20111109 
US20100005309A1 (en)  20100107 
US8256015B2 (en)  20120828 
Similar Documents
Publication  Publication Date  Title 

US8256015B2 (en)  Method and apparatus for authentication of data streams with adaptively controlled losses  
US7558954B2 (en)  Method and apparatus for ensuring the integrity of data  
Park et al.  Efficient multicast stream authentication using erasure codes  
US7685415B2 (en)  Exclusive encryption  
US7298840B2 (en)  Method and system for data integrity protection  
US7581094B1 (en)  Cryptographic checksums enabling data manipulation and transcoding  
US10263783B2 (en)  Method and system for authenticating a data stream  
JP5392102B2 (en)  Apparatus and method for reducing overhead in a wireless network  
Sun et al.  Qualityoptimized and secure endtoend authentication for media delivery  
Zhang et al.  An optimized contentaware authentication scheme for streaming JPEG2000 images over lossy networks  
US20080273693A1 (en)  Efficient encoding processes and apparatus  
RU2638639C1 (en)  Encoder, decoder and method for encoding and encrypting input data  
Pannetrat et al.  Authenticating real time packet streams and multicasts  
Habib et al.  A treebased forward digest protocol to verify data integrity in distributed media streaming  
Gentry et al.  Endtoend security in the presence of intelligent data adapting proxies: The case of authenticating transcoded streaming media  
Deng et al.  A study of content authentication in proxyenabled multimedia delivery systems: Model, techniques, and applications  
Wang et al.  Energydistortionauthentication optimized resource allocation for secure wireless image streaming  
Habib et al.  Verifying data integrity in peertopeer media streaming  
WO2002091668A2 (en)  Method and system for data integrity protection  
Zhu et al.  A joint layered coding scheme for unified reliable and secure media transmission with implementation on JPEG 2000 images  
Tartary et al.  Achieving multicast stream authentication using MDS codes  
Gennaro  Cryptographic algorithms for multimedia traffic  
CN112163171A (en)  Data chaining method based on terminal signature  
Wu et al.  Contentaware authentication of motion JPEG2000 stream in lossy networks  
Tartary et al.  Combining prediction hashing and MDS codes for efficient multicast stream authentication 
Legal Events
Date  Code  Title  Description 

AS  Assignment 
Owner name: DOCOMO COMMUNICATIONS LABORATORIES USA, INC., CALI Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GENTRY, CRAIG B.;HEVIA, ALEJANDRO;JAIN, RAVI KUMAR;AND OTHERS;REEL/FRAME:015126/0015;SIGNING DATES FROM 20040805 TO 20040830 

AS  Assignment 
Owner name: NTT DOCOMO INC., JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DOCOMO COMMUNICATIONS LABORATORIES USA, INC.;REEL/FRAME:017213/0760 Effective date: 20051107 Owner name: NTT DOCOMO INC.,JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DOCOMO COMMUNICATIONS LABORATORIES USA, INC.;REEL/FRAME:017213/0760 Effective date: 20051107 

STCB  Information on status: application discontinuation 
Free format text: ABANDONED  FAILURE TO RESPOND TO AN OFFICE ACTION 