CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 61/377, 1 18, filed August 26, 2010, the contents of which are hereby incorporated by reference in its entirety.

BACKGROUND

[0002] Network communications may be sent from a sending device at a sending network to a receiving device at a receiving network. The sending network and/or the receiving network may be an IP -Multimedia Subsystem (IMS) for example. In some cases, it may be difficult for the receiving network to evaluate the received communications. This difficulty may arise because the received communications are being sent from a sending device at another network for example. Additionally, the sending network and the receiving network may be in different domains.

[0003] Due to the difficulty in evaluating communications at a receiving network, the integrity and/or trustworthiness of the communication may be difficult to determine. As a result, a user of a receiving device may receive unsolicited communications (UCs) (e.g. calls, text messages, or other unwanted messages) from a sending device.

SUMMARY

[0004] This Summary is provided to introduce various concepts in a simplified form that are further described below the Detailed Description.

[0005] Systems, methods, and apparatus embodiments are described for assessing, at a receiving domain, a trustworthiness of a sender, at a sending domain. As described herein, a scorecard may be received, at a receiving domain. The scorecard may include information relating to the trustworthiness of a sender of a communication sent from a sending device, at a sending domain. The trustworthiness of the sender may be assessed based on a verification of the scorecard information. The communication from the sending device may be allowed to be received by a receiving device, at the receiving domain, when a result of assessing the trustworthiness of the sender indicates that the sender is trustworthy. [0006] Systems, methods, and apparatus embodiments are also described for verifying, at a receiving domain, claims of a scorecard associated with a sender, at a sending domain. As described herein, a scorecard associated with the sender, at the sending domain, may be received at the receiving domain. The scorecard may include a claim associated with the scorecard. The claim may indicate a trust property associated with the sender or a sending device associated with the sender. The claim of the scorecard may be verified and an indication may be added to the scorecard indicating that the claim has been verified. The scorecard may be sent to a scorecard proxy.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to any limitations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0009] Figure 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0010] Figure IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0011] Figure 2 illustrates an exemplary XML implementation for a scorecard;

[0012] Figure 3 illustrates an exemplary network architecture;

[0013] Figure 4 illustrates an exemplary network architecture with SC-APs and SC- DBs; and

[0014] Figure 5 illustrates an exemplary call flow relating to a scorecard

implementation.

DETAILED DESCRIPTION

[0015] Systems, methods, and apparatus may be described herein for determining the trustworthiness of a sender of a network communication. For example, information relating a sender of a communication may be generated and/or aggregated in a scorecard. The information (e.g., a score value) in the scorecard may be assessed to determine the trustworthiness of the sender. The information in the scorecard may be verified for authenticity by tracing back to a trusted third party. If the information in the scorecard satisfies a predefined rule (e.g., a user- and/or operator defined policy) a connection between the sender and an intended receiver may be allowed.

[0016] A sender scorecard may comprise an electronic signed message or token that incorporates information elements. A scorecard may be built from multiple entries. Each entry in the scorecard may include a category, a claim which defines the trust property in the category, a score that is globally and/or locally defined and comparable to scores associated with other claims, and an attribute/state field which keeps track of the state of the claim.

[0017] A scorecard may be associated with a sending device in a sending domain attempting to communicate with a receiving device in a receiving domain. A scorecard may be provided by a scorecard issuer (SC-I) associated with the sending domain. The SC-I may be responsible for verifying claims to be included in the scorecard. The SC-I may forward the scorecard, together with a session initialization message from the sender, to a scorecard proxy (SC-P), which may be located at the receiving domain. The SC-P may verify that the receiver is indeed in the receiving domain and/or forward the scorecard to a scorecard verifier (SC-V). The SC-V may evaluate the scorecard and/or verify the claims included in the scorecard. The result of the scorecard validation may be sent to the SC-P, which may make a decision based on the outcome of the validation process by the SC-V.

[0018] Figure 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0019] As shown in Figure 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a reader, a personal computer, a wireless sensor, consumer electronics, and the like.

[0020] The communications systems 100 may also include a base station 114a and a base station 1 14b. Each of the base stations 1 14a, 1 14b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 1 12. By way of example, the base stations 1 14a, 1 14b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and/or the like. While the base stations 1 14a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 1 14b may include any number of interconnected base stations and/or network elements.

[0021] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 1 14a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0022] The base stations 114a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 1 16 may be established using any suitable radio access technology (RAT).

[0023] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA,

TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 1 14a in the

RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 1 16 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0024] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 1 16 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0026] The base station 114b in Figure 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 1A, the base station 114b may have a direct connection to the Internet 1 10. Thus, the base station 114b may not be required to access the Internet 1 10 via the core network 106.

[0027] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0028] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in Figure 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0030] Figure IB is a system diagram of an example WTRU 102. As shown in Figure IB, the WTRU 102 may include a processor 1 18, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0031] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate

Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.

The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Figure IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 1 16. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0033] In addition, although the transmit/receive element 122 is depicted in Figure IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 1 16.

[0034] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1, for example.

[0035] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown). [0036] The processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0037] The processor 1 18 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 16 from a base station (e.g., base stations 114a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0038] The processor 1 18 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0039] The aforementioned communication systems, or portions thereof, may be used for determining the trustworthiness of a sender of a communication, as described herein. For example, the communication systems, or portions thereof, may be used for generating and/or implementing scorecards related to a sender of a network communication. The use of scorecards may relate to network security. For example, scorecards may be used as a source of protection from unsolicited communication (UC), such as for Protection against Unsolicited

Communication for IP -Multimedia Subsystem (PUCI) for example. However, the concepts disclosed herein are not meant to be limited to such systems and may be applied to other communications systems.

[0040] Network entities used to generate and/or transport sender information across, or within, different identifier domains (e.g. , IMS and non-IMS networks) may provide reliable assurance on different properties of a sending UE to the receiving domain. The establishment, verification, and/or certification of properties may be different between IMS and non-IMS networks. Using scorecards, a network entity in a receiving domain may be able to verify received information from an entity in a sender domain. Using such information, the receiving domain may be able to build a decision on whether to allow or disallow communication with a receiving UE in the receiving domain.

[0041] A sender scorecard may comprise an electronic signed message or token that may be verifiable for authenticity by way of a cryptographic integrity check. The scorecard may incorporate information elements (e.g., quantifiable in numeric terms, qualitative and/or heuristic) that may enable trust to be assessed and that may be passed around a network and/or verified for authenticity by tracing back to a trusted third party.

[0042] A scorecard may be built from multiple entries. Each entry may have a category, a claim that defines a trust property in the category, a score that may be globally and/or locally defined and comparable, and/or an attribute/state field that keeps track of the state (e.g., verification state) of the claim. The claim indicates a trust property associated with the sender or the sending device. The category includes a group of claim types that are directed to the same, or similar, trust properties. Examples of various categories may include an identification category, a device category, a reputation category associated with the reputation of a sender and/or sending device, a capability category, a security architecture category, and/or a policy category. The score includes an information element (e.g., a numerical value) that is associated with a claim that enables the claim to be comparable to one or more other claims. For example, the score may be a value from one to ten, indicating the level of trustworthiness associated with a claim compared to other claims. The attribute/state field indicates whether the claim has been verified and/or its trustworthiness. The attribute/state field may carry a timestamp to indicate the time of the verification of the claim (e.g., the claim may be valid from a certain time). The attribute/state field may include an entity that has verified an associated claim. Table 1 illustrates an exemplary scorecard with a number of entries.

Category Claim Score Attribute/State

Identification (ID) Authenticated using username/password 3 Verified by At ...

Identification (ID) Can be resolved to a physical identity 9 Verified by At ...

Device (dev) Is certified by manufacturer 4 Verified by At ... Device (dev) Has been integrity checked 8 Verified by At ...

Reputation Reputation score in community X is HIGH 6 Verified by At ...

Capability Device capabilities e.g. policies which it Verified by follows, functionality etc.

At ...

Security architecture Security functionality/architecture of device, Verified by e.g. trust module certification, software certification etc.

At ...

Policy Security and/or compliance policies which Verified by device follows etc.

At ...

Table 1 - Example Scorecard

[0043] One example embodiment for implementing a scorecard may include an XML scheme that may provide portability across different domains. Figure 2 illustrates an exemplary XML implementation for a scorecard. The exemplary scheme may be embedded and/or complemented by SAML assertions and/or XML signatures. With the use of SAML assertions, scorecards may be implemented in which different claims are verified and/or signed by different entities. This may allow for a heterogeneous approach, where no one single entity verifies the claims before the scorecard is issued. Instead, each claim verifier may rely on assertions made by other claim verifiers.

[0044] As illustrated in Figure 2, a scorecard 202 may include a category 204, a claim 208, a score 214, and/or an attribute/state 218. The category may include a category ID 206 that identifies the category type. The claim 208 may include claim text 210 indicating a trust property associated with the sender of a network communication or a sending device associated with the sender. The claim 208 may also include a unique identifier 212 that identifies the claim 208 and/or the claim text 210. The score 214 may include a score value 216 that indicates a trustworthiness of a sender of the communication. The attribute/state field 218 may include a claim verifier 220 that indicates an entity that has verified the claim 208 and/or its

trustworthiness. The attribute/state field 218 may also include a timestamp 222 and/or signature 224 further indicating the trustworthiness of the claim verification. Although an XML scheme has been used to illustrate a possible scorecard implementation, any implementation providing features disclosed herein may be used. [0045] Scorecards may be generated by an intermediate architectural layer between the sending device and receiving device of a communication. According to one embodiment, a scorecard architecture may be used for PUCI. An exemplary scorecard architecture is illustrated in Figure 3. As illustrated in Figure 3, the scorecard architecture may include one or more domains, such as Domain A 302 and/or Domain B 304 for example. Domain A 302 may be owned by an IMS non-compliant operator, while Domain B 304 may be owned by an IMS compliant operator. However, a person of ordinary skill in the art would understand that each of Domain A 302 and Domain B 304 may be owned by either an IMS compliant or IMS non- compliant operator. Domain A 302 may include one or more networks, such as Network A 306 and/or Network C 310. Domain B 304 may also include one or more networks, such as Network B 308. As described herein, Network A 306 may be a sending network, for sending a communication to another network, while Network B 308 and/or Network C 310 may be receiving networks, for receiving a communication from another network. Network A 306, may include one or more UEs, such as UE A 312, a proxy 314, a scorecard proxy (SC-P) 316, an outbound proxy 318, a scorecard issuer (SC-I) 320, and/or a scorecard verifier (SC-V) 322. Network B 308 may include one or more UEs, such as UE B 324, an OI-SCF 326, an SC-P 328, a P-CSCF 330, an SC-V 332, and/or an SC-I 334. While Network C 310, may include the same, or similar, network entities as described herein for Network A 306 and/or Network B 308, as illustrated in Figure 3, Network C 310 includes a UE C 336 and a Proxy 338. The scorecard architecture illustrated in Figure 3 also includes a scorecard database (SC-DB) 340. SC-DB 340 may be a global or local database used by one or more networks and/or domains. SC-DB 340 may include one or more databases. According to one example, SC-DB 340 may include a different database for each of Network A 306, Network B 308, and/or Network C 310.

According to another example, SC-DB 340 may include a different database for each of Domain A 302 and Domain B 304.

[0046] A communication may be initiated from by a sending user equipment (UE) A

312 for receipt by a receiving UE at a different domain, such as UE B 324 for example. The communication may also, or alternatively, be initiated by UE A 312 for receipt by a UE in the same domain, such as UE C 336 for example. The communication may be a phone call, text message (e.g., SMS, MMS, and/or TMS), and/or other network communication for example.

After the initiation of a communication, a scorecard may be provided by a SC-I, such as SC-I

320 and/or SC-I 334. According to one embodiment, after UE A 312 initiates a communication,

SC-I 320 and/or SC-I 334 may receive indication that UE A 312 has initiated a communication.

The indication may be received from UE A 312 and/or Proxy 314. [0047] After receiving the indication, SC-I 320 may provide a scorecard associated with the communication. When UE A 312 wants to establish an IMS connection, it may request a scorecard from the SC-I 320. The SC-I 320 may be responsible for verifying claims to be included in the scorecard. The SC-I 320 may verify the claims and/or sign them. According to another embodiment, if no scorecard is generated in sending Domain A 302 (e.g., if SC-I 320 is not present or not implemented) a scorecard may be generated using SC-I 334 at receiving Domain B 304. The SC-I 334 may act in the same, or similar, manner as described herein with regard to SC-I 320 for example.

[0048] The SC-I 320 and/or SC-I 334 may forward a scorecard to SC-P 328 at the receiving Domain B 304. According to one implementation, the scorecard may be sent together with a session initialization message from the sender. The SC-P 328 may verify that the receiving UE B 324 is in Domain B 304 and/or forward the scorecard to a scorecard verifier (SC- V) 332. The SC-V 332 may evaluate the scorecard and/or verify the given claims. The result of the scorecard validation may be sent to SC-P 328. The SC-P 328 may make a decision based on the outcome of the validation by SC-V 332. For example, if the outcome of the validation by SC-V 332 is positive, SC-P 328 may allow the communication from UE A 312 to be received by UE B 324. Alternatively, if the outcome of the validation by SC-V 332 is not positive, SC-P 328 may disallow the communication from UE A 312 to be received by UE B 324. The decision may also, or alternatively, be based on other factors. For example, the decision may be based on user- and/or operator-defined policies. According to one exemplary implementation, per a policy, a connection between UE A 312 and UE B 324 may not be established if a scorecard has one or more low scores. A score may be determined to be high or low relative to other scores in scorecards used within the same and/or different domains. If the SC-P 328 allows the communication, the connection may be established between UE A 312 and UE B 324.

[0049] The SC-P 328 may be used as a network gatekeeper. For example, the SC-P 328 may provide user-centric services to UE B 324. The user-centric services may be provided via P-CSCF 330 based on scorecard information for example. One such exemplary service may be to keep a per-receiving UE history of accepted calls and/or UC classified calls, together with corresponding scores. Statistics on user call acceptance and/or rejection behavior may be used to educate a user's decision on taking a call. The caller's scorecard may also be presented at various detail levels. After a call, the SC-P 328 may obtain an assessment by the user to determine a subjective, receiver-informed qualification of a UC. This data may be correlated back with scorecards to improve the mapping of the set of scores to UC probability, such as by statistical feedback learning for example. [0050] Outbound Proxy 318 is an outbound proxy that may be used to provide a connection between Domain A 302 and Domain B 304, such as when Domain A 302 is a non- IMS domain and Domain B 304 is an IMS domain for example. Proxy 314 and Proxy 338 are inbound proxies that may implement call routing functions within Domain A 302 and Domain B 304, respectively. Proxy 314 and Proxy 338 may allow multiple UEs to connect to their respective domains for inbound calls. OI-SCF 326 is an inbound proxy in Domain B. OI-SCF 326 may serve "open" interconnections, rather than IMS interconnections for example. OI-SCF 326 may also serve to translate communications from non-IMS to IMS communications.

[0051] While Network A 306 may be described herein as the sending network and Network B 308 may be described herein as the receiving network for a network communication, Network A 306 may be used as the receiving network and/or Network B 308 may be used as the sending network. According to this embodiment, SC-P 316 and SC-V 322 in Network A 306 may perform in the same, or similar, manner as SC-P 328 and SC-V 332 in Network B 308 respectively, as described herein.

[0052] SC-DB 340 may be queried by SC-I 320 and/or SC-I 334. SC-DB 340 may include reference scores for different claims. A score may represent the strength of an associated claim in relation to other possible claims. For example, the score may represent a strength in relation to claims in the same or similar categories. The strength of the score may indicate a level of trustworthiness associated with a claim. For example, if a user provides his full name and address to the operator and the operator verified the name and address (e.g., by an out of band process), this claim may get a higher score than a disposable email address. The email address, however, may have a slightly higher score than a mere pseudonymous username.

[0053] SC-DB 340 may be comprised of different, domain specific SC-DBs. For example, SC-DB 340 may include a different SC-DB for each category in a domain. This may enable each domain to make a decision based on the score differently and/or independently. For example one domain may give a higher score for two-factor authenticated identities than another domain. The scores may include an indication of the SC-DB from which they have been derived.

[0054] When SC-DB 340 is implemented, SC-I 320 and/or SC-I 334 may look up the score for one or more claims and/or include the score value in the scorecard. SC-I 320 and/or

SC-I 334 may also verify the claim. If verification is successful, the SC-I 320 and/or SC-I 334 may add a statement on successful verification of the claim. The statement may include a timestamp of the time in which verification occurred. The statement and/or timestamp may be included in the attribute field for the corresponding verified claim in the scorecard. [0055] Other implementations may be employed at the SC-I 320 and/or SC-I 334, such as relying on claim assertions made by other trusted third parties and/or verifying a subset of the scorecard for example. The scorecard may be uniquely identifiable. The SC-I 320 and/or SC-I 334, which issued the card, may be identified by the scorecard. For example, the SC-I 320 and/or SC-I may provide a timestamp and/or a signature on the final scorecard. The scorecard may be signed in a way that allows for renewal of some of the claims therein. A receiving UE may re -use part of a previously issued scorecard, but may update a part of it.

[0056] According to one embodiment, as an alternative or in addition to an independent SC-I, a UE may incorporate part, or all, of the SC-I functionalities in a secure environment SC-I- Device (SC-I-Dev). For example, UE A 312 may incorporate the functionality of SC-I 320. A scorecard may be issued by SC-I 320 to a SC-I-Dev of UE A 312 and securely stored therein. The SC-I-Dev of UE A 312 may add additional claims to the scorecard received from SC-I 320. For example, it may add claims about device integrity to the scorecard. The SC-I-Dev of UE A 312 may sign the additional claims and/or send the scorecard to another entity (e.g., in a communication initiation attempt). The SC-I-Dev of UE A 312 may send the scorecard to SC-I 320, or to an entity in the receiving Domain B 304. SC-I 320 may provide its own signature to the scorecard and/or forward it to an entity in the receiving Domain B 304.

[0057] The scorecard may be protected against manipulation by an unauthorized party by secure storage associated with the SC-I-Dev for UE A 312. The secure storage for scorecards may be provided by a secure element (e.g., a UICC, a smart card, a Trusted Platform Module, a Trusted Environment, a TRM, a Trust Zone, and/or other secure element) within the UE. The secure element (e.g., a UICC, a smart card, a Trusted Platform Module, a Trusted Environment, a TRM, a Trust Zone, and/or other secure element) used to securely store the scorecard may alternatively, or additionally, be external to the UE. The secure element may be

cryptographically bound to the UE (e.g., using a secure external token, such as a secure memory card for example, that may interact with the secure environment of the UE). In one exemplary embodiment, the SC-I-Dev for UE A 312 may reside on a smart card, such as the UICC for example, of UE A 312 for example. While the SC-I-Dev may reside on a smart card, other implementations may be used to provide security to the SC-I-Dev of UE A 312.

[0058] UE B 324 and/or UE C 336 may similarly incorporate the functionality of an SC-I using an SC-I-Dev as described herein. For example, UE B 324 may include an SC-I-Dev that incorporates the functionality of SC-I 334.

[0059] The integrity of the information in the scorecard may be protected (e.g., if desired and/or required for confidentiality) using various options described herein. While various different options are described herein, a person of ordinary skill in the art would recognize that the different options may be used separately or combined. In one option, the SC-I 320 and/or SC-I 334 may sign the complete scorecard. The complete scorecard may be signed even if the SC-I 320 and/or SC-I 334 did not verify each claim in the scorecard. In another option, the SC-I 320 and/or SC-I 334 may sign the scorecard if the claims have been verified, signed, and/or certified by another trusted party. In another option, the SC-I 320 and/or SC-I 334 may sign the claims that they may verify. In another option, group signatures may be used. In another option, the SC-I 320 and/or SC-I 334 may verify unverified claims. For example, the SC-I 320 and/or SC-I 334 may use indicators to responsible information providers which may be included in the claims and/or may be retrieved from the SC-DB 340.

[0060] Figure 4 illustrates an example architecture that may be used to verify unverified claims. Figure 4 illustrates the sending Network A 306, having SC-I 320 for example. SC-I 320 may include an indication in the scorecard that indicates that a claim has been validated and/or authenticated. For example, the indication may include the responsible information provider that has the validation and/or authentication information. The indicators may be included in the scorecard based on information received from an information provider or a SC-DB. For example, as illustrated in Figure 4, the SC-I 320 may call one or more different information providers, such as Device Information SC-AP 402, Reputation Information SC-AP 404, and/or Identity Information SC-AP 406. The referred information provider may be a platform verification entity (PVE) for device validation and/or an authentication server for identity information for example.

[0061] The PVE may be a trusted entity that assesses the trustworthiness of a UE. For example, the PVE may assess the trustworthiness of sending UE 312, using software integrity checking procedures for example. The PVE may assess the trustworthiness of sending UE 312 and incorporate an indication of the trustworthiness of the UE into the scorecard. For example, the indication may include a result of a verification check performed by the PVE. According to one embodiment, the scorecard may be created, offered to the PVE for signing, and/or returned to the sending UE 312 or SC-P 316 for circulation to other parties. Alternatively, the PVE may collect the scorecard information, include the validation result, sign the scorecard, and/or return the scorecard to the sending UE 312 or SC-P 316.

[0062] The information providers may provide assertions on the presented claims and may be referred to as Assertion Providers (SC-APs). As illustrated in Figure 4, the SC-APs 402,

404, 406 may be situated outside of a network (e.g., Network A 306) and/or a domain (e.g.,

Domain A 302). The SC-APs 402, 404, 406 may be queried by an SC-I, such as SC-I 320 for example. Each of the SC-APs 402, 404, 406 may be associated with a different category of claims. For example, in response to a query, Device Information SC-AP 402 may provide assertions on claims associated with UE 312, Reputation Information SC-AP 404 may provide assertions on claims associated with a reputation of UE 312 and/or a user of UE 312, and/or Identity Information SC-AP 406 may provide assertions on claims associated with an identity of UE 312 and/or a user of UE 312.

[0063] If the SC-I 320 queries one or more of the SC-APs 402, 404, 406, the SC-I 320 may include a notification in the claim indicating that an SC-AP has been used and/or which SC- AP has been used. The notification may be in the attribute field associated with the claim for example. The notification may be used because the receiving domain's SC-V, such as SC-V 332 illustrated in Figure 3 for example, may not able to verify the assertion being made by an SC-AP.

[0064] Additionally, or alternatively, the SC-I 320 may retrieve indications of authentication and/or validation information from the SC-DB 340. The SC-DB 340 may include one or more different SC-DBs for each category or type of indicator being retrieved by the SC-I 320. For example, SC-DB 340 may include SC-DB 408, SC-DB 410, and/or SC-DB 412. SC- DB 408 may include indicators for authentication and/or validation of a reputation associated with UE 312 and/or a user of UE 312. SC-DB 410 may include indicators for authentication and/or validation of an identity associated with UE 312 and/or a user of UE 312. SC-DB 412 may include indicators for authentication and/or validation of UE 312.

[0065] Referring back to Figure 3, as discussed herein the SC-V 332 of the receiving Network 308 may verify the received scorecard. As different domains may use different types of claims, the claims may be categorized and their score may be looked up by the SC-V 332 at SC- DB 340, which may include one or more, different, SC-DBs. For example, each SC-DB of the different SC-DBs may be a third-party SC-DB, an independent SC-DB, an official SC-DB, a governmental SC-DB, a trans -national SC-DB, and/or a global SC-DB.

[0066] According to an embodiment, the scorecard verifier SC-V 332 may be involved in the verification of certain types of claims (e.g., evaluation of device integrity measurements). Claim validation related tasks may be performed in the sending Network A 306 by the respective SC-I 320. For example, the claim validation may be performed upon creation of the scorecard in which the claim resides. The SC-V 332 may determine if the scorecard is valid, if the included claims are compliant to domain/user specific rules, and/or if the issuing SC-I 320 is trustworthy.

[0067] SC-V 332 may verify freshness of a claim and/or a scorecard. For example, SC- V 332 may verify the length of time since a claim and/or a scorecard have been issued. If the length of time exceeds a predetermined amount of time, then the claim and/or scorecard may no longer be valid.

[0068] Several options may be employed to evaluate received and/or generated scorecards. While various options are described herein, a person of reasonable skill in the art would understand that these are not the only options for evaluating a scorecard and that the different options may be combined in various ways.

[0069] Calculation of a score for a claim and/or scorecard may follow different rules. The rules may be domain-specific for example. Alternatively, or additionally, the rules for calculation of a score for a claim may be standardized across one or more networks and/or domains. The rules for calculation of a score in a scorecard may be indicated on the scorecard.

[0070] In one option, scorecards may be evaluated in total. For example, the total score of the scorecard may equal the lowest score in the scorecard and/or across the categories of the scorecard. In another option, scorecards may be evaluated by categories. For example, the lowest score for a category may determine the category score. In another option, scorecards may be evaluated by a weighted distribution formula that allows users and/or operators to define different weights for different claim types or categories. In another option, the receiving network may keep network scores for each sending network. The network scores may express the level of trustworthiness the receiver has in the sending domain's SC-I. The individual caller or calling device's scorecard from a sending network with an existing network score may be weighted by the network score. A domain may have individual and non-uniform weighting mechanisms for other networks. A new sending network, which may not be known by the receiver, may start with a network score which is below the lowest network score known to the receiver. A network score may be increased by different mechanisms (e.g., reputation, agreements between domain operators and/or certifications of domains). In another option, a receiving network may, in the case of an un-trusted sender network for example, rank the information received from a sender's network based on the actual measured data of the sender's device and based on the history of information received from that sender's device.

[0071] The SC-I 320 and/or SC-I 334 may issue another scorecard for each

communication attempt being made. Such a scorecard may not be able to be used by another device to determine trustworthiness of a sender and/or sending device (e.g., redistribution may be impossible or useless). Alternatively, the SC-I 320 and/or SC-I 334 may issue a scorecard that is re-usable. The scorecard may include one or more timestamps to indicate the freshness of a claim or claim verification. According to one implementation, the scorecard (or part of it) may be encrypted with a secret which may be known to the sending device. The device may present reliable evidence of its capabilities, that it may store the scorecard securely, and that the key used for encryption and decryption is protected by the device. Standardized device profiles (e.g., OMTP TR1 profiles or the like) may be used for interoperability of heterogeneous networks, such as where multiple different devices from different vendors with varying hardware and/or software capabilities may interact for example.

[0072] The device may decrypt the scorecard when initiating a communication session and/or present the scorecard to the SC-P 328 of receiving Domain B 304. Such a scheme of reusable scorecards may reduce network traffic and/or computational efforts for the SC-I 320 and/or SC-I 334, but may increase requirements on the device side. If the scorecard contains strong, verified, identity information, and satisfies the conditions of device binding as described herein, the scorecard may provide high assurance about the identity and/or properties of the party initiating communication. It may then have the information of a credential as is commonly used in Identity Management (IdM) systems. It may be useful for the SC-P 316 in sending Network A 306 and SC-P 328 in receiving Network B 308 to consider and/or use such Id-enabled scorecards in lieu of access credentials.

[0073] An exemplary call flow is illustrated in Figure 5. As illustrated in Figure 5, scorecards may be re -used toward various receiving networks. For example, SC-P 520 may be singled out as an identity provider for card-bound identities, for example after first receipt and positive assessment of a particular card. The SC-P 520 may announce its Identity Provider (IdP) role for this particular card in a central directory so that other receiving networks called by that user could look up this directory. There, the SC-P 516 of a subsequently called Network C 506 may select one card IdP SC-P, such as the one with freshest assessment information on the scorecard's claims, for example, (e.g., the directory entries may bear time-stamps) to vouch for the identity and integrity of that caller and obtain an Id assertion. This may avoid having to locally verify the claims of that scorecard.

[0074] In an exemplary embodiment, a sending network, such as Sender Network A 502, may keep a store of used, but re -usable scorecards. The call flow of Figure 5 may use elements not illustrated therein, (e.g., replay and/or integrity protection).

[0075] As illustrated in Figure 5, at 1, a UE 508 in Sender Network A 502 may initiate a communication (e.g., call, text message, or other network communication) to UE 512 in

Receiving Network B 504. Proxies and/or gateways may be included in initiating the communication, but are omitted from Figure 5 for simplicity. Along with the communication being initiated at 1, a scorecard may be sent at 1 to SC-P 520 in Receiving Network B 504. In an alternative embodiment, the scorecard may be sent before or after the initiation of the communication. SC-P 520 may assess the scorecard at 2. Upon positive result, the SC-P 520 may forward the communication to the target UE 512. According to one embodiment, the communication may be forwarded to UE 512 via the C-CSCF 524 at 3. As shown at 3', receiving UE 512 may notify SC-P 520 that the call was not a UC. The SC-P 520 may create a scorecard IdP binding.

[0076] SC-P 520 may store the scorecard and/or assessment result in a local scorecard Identity Database SC-LIDB 522 at 4. At 4a, the SC-P 520 may publish its association as IdP to this scorecard in a directory SC-IDD 518. The SC-IDD 518 may be a public or private directory for example. Data sent to the SC-IDD 518 may comprise the ID of SC-P 520, a unique ID of the scorecard, a lifetime (e.g., length of time) for this IdP association, and/or other data such as integrity/replay protection or metadata for example. At 4' SC-P 520 may explicitly notify UE 508 of Sender Network A 502 of the lifetime of the IdP commitment made. From this, the Sender Network A 502 may determine when to issue another scorecard or re-use the same one.

[0077] At another time, the sender UE 508 in Sender Network A 502 may initiate a communication to UE 510 in Receiving Network C 506. The UE 508 may send the same scorecard to SC-P 516 at 5 as it sent to SC-P 520 at 1. According to one embodiment, the scorecard may be sent to the SC-P 516 without knowing the lifetime of the scorecard. For example, the Sender Network A 502 may follow a policy to re-use a scorecard until failure. The Sender Network A 502 may generate another scorecard when a receiving network rejects the scorecard as being too old (e.g., exceeding its lifetime or a predetermined period of time since issuance). Alternatively, the Sender Network A 502 may analyze the validity of the scorecard before sending to Receiving Network C 506.

[0078] After the SC-P 516 receives a scorecard from UE 508 at 5, SC-P 516 may look for and/or retrieve an SC-IdP association stored in SC-IDD 518 at 6. At 7, SC-P 516 may request and/or obtain a scorecard identity assertion from SC-P 520 at Receiving Network B 504. SC-P 520 may query SC-LIDB 522 and/or receive the scorecard identity assertion from SC- LIDB 522 at 8. After the SC-P 516 obtains the scorecard identity assertion at 7, the

communication initiated by UE 508 may be forwarded to UE 510. For example, the communication may be forwarded via C-CSCF 514 at 9.

[0079] Scorecards as described herein may be used by network entities to transport communication (e.g., call, text message, or other network communications) related information across, or within, different domains. However, it may be beneficial to forward scorecard information to the network entities (e.g., receiving UE). Scorecard information may be expressed in a score that may be calculated by an SC-V and/or SC-P in the receiving domain. The score may be forwarded to the receiving UE. The user of the receiving UE, and/or the receiving UE itself, may evaluate the score and make an independent assessment of the score (e.g., in addition to the network assessment by the SC-V and/or the SC-P). After accepting the call, the receiving UE may give feedback in the form of a rating of the call which the network operator may include in its future score derivations for future scorecards. A receiving UE may also be able to receive more information than a score. Such a receiving UE or user of the receiving UE may want to have more feedback than the score value, to have greater control over future grading of UC by the network operator.

[0080] Different categories may be provided for the claims in a scorecard. Each category may be associated with a similar type of claim. For example, a different category may be established for claims directed to device information, integrity information associated with a UE and/or a user of the UE, and/or reputation information associated with a UE and/or a user of the UE. There may be independent SC-DBs for claim categories (e.g., a device SC-DB, an integrity SC-DB, and/or a reputation SC-DB). The contents of the SC-DBs and/or the categories may be standardized for interoperability within and/or between different domains. The scorecard may include multiple categories and/or sub-categories.

[0081] Optional scorecard implementations are described herein. While various different options are described herein, a person of ordinary skill in the art would recognize that the different options may be used separately or combined.

[0082] In one option, a scorecard may include different types of scores, such as 1) instantaneous, per-communication data, and/or 2) long-term, average or historic data for example. Instantaneous, per-communication data may be retrieved by a SC-I at the time the call is initiated in the sending domain. Long-term, average, or historic data may be collected over time. A SC-I may store data on former caller behavior, reputation, and/or feedback to derive the long-term, average data. A claim may be based on instantaneous, per-call data or on long-term, average data. At least two options for the inclusion of additional information on the type of data may include: as an attribute per claim or as a meta-category on top of existing categories.

[0083] As another option, if the type of data (e.g., per-communication or historic) is associated with a single claim in the scorecard, a SC-I may use the attribute field in the scorecard to include information on the type of data which was used to verify the claim.

[0084] As another option, the modular design of the scorecards may enable definition of the type of data (e.g., per-communication or historic) as meta-categories. Such a scorecard may be divided into at least two sections, one that may comprise the per-communication claims and one that may comprise the historic data, collected claims. In each of the two top-level categories, there may be sub-categories, (e.g., the categories may include identification information, device information, reputation information, and, for the historic data, there may additionally be the behavior in earlier calls).

[0085] The claim verification and issuance may be separated into different categories as well. For example, an entity that may verify and/or validate the trustworthiness (e.g., authenticity and/or integrity) of a device and/or its underlying platform (e.g., Operating System, underlying low-level codes and hardware) may be contacted for information on device validation, IdP for identity authentication, or the like. U.S. Patent Application 12/563,392, filed September 21, 2009, which is hereby incorporated by reference in its entirety, may provide examples of such verifying entities.

[0086] A scorecard may support information on sender identity. The identity category may use the category name ID. The ID category may use a number of fields, including, but not limited to, an identity authentication scheme field, an identity assurance level field, and/or an identity properties field. The identity authentication scheme field may include username and/or password information, a two-factor hardware token, a two-factor software token, biometrics information, and/or user authentication information that indicates the trustworthiness of the device the user uses for identification. The identity assurance level field may be resolved to a physical address and/or an entity that may be made liable for any action taken. The identity properties field may include a name, country, company, age, and/or gender information.

[0087] Some fields may include authentication credentials or references to them. One example may be the inclusion of a signed challenge (e.g., if public key crypto authentication is used). References to credentials may be of a type that allows unique and/or reliable resolving to the referenced data. The use of extensible resource identifiers (XRI) may allow creation of a structured scheme with tags, which may be interoperable across domains, and/or may allow a persistent link to a possibly moving network resource.

[0088] Trusted sender identities may be included in the scorecard (e.g., as an extension to the identity information). By the inclusion of trusted sender identities in a scorecard, the scorecard may have a higher score. Additionally, the inclusion of trusted sender identities, using the methods described herein, may include references to verifiable trustworthy information. This may enable a receiving SC-V to perform an independent trust-assessment on the specific identity claim.

[0089] The sender-identity authentication mechanism may include information about the trustworthiness of the device the sender uses to send identity information. The sender- identity authentication mechanism may incorporate the claim field for identity authentication in the sender scorecard to include the trusted ticket (or a reference to a third party from which it may be obtained) used to convey the information about the trustworthiness of the sender's device. This may allow a receiving SC-V to verify the given claim independently. The SC-V may verify the ticket (e.g., by taking it from the scorecard or by reading it from the reference pointer). After successful verification, the SC-V may add its own signature and/or timestamp to the attribute field of the scorecard.

[0090] In the device category, which may be denoted by 'dev,' device related information may be provided. The device category may include, but may not be limited to, a vendor id, a device id, a device type (e.g., handset, laptop, corporate network, or VoIP phone), a software version, a firmware version, a device certification, device integrity validation information, a device integrity validation result, a device integrity validation measurement, an IP address, GSM/UMTS/LTE cell information, a geolocation, ownership information (e.g., "this device is the property of organization XXX"), intended or typical usage of the device (e.g., making VoIP phone calls or using social networking sites), intended restrictions on the usage of the device, device security capability information (e.g., "the device has a secure crypto processor capable of performing AES-CCM- 128 bit encryption"), and/or device security certification level information (e.g., if the device meets Common Criteria EAL-3 or 4 levels).

[0091] Reputation-based scores may be included in the scorecard. A reputation-based score may be based on a reputation or network of reputations. The scorecard may include information on the behavior of the sender and/or sender UE. Such information may be collected by user feedback mechanisms. For example, a user of a receiving UE and/or the receiving UE itself may provide feedback based on a communication from a sending UE. Such data in the scorecard may be based on historic (e.g., averaged or long-term) data, which may be kept by a SC-I or a database that may be accessed by the SC-I. According to one embodiment, a communication from a user and/or UE may be marked as a potential UC, but may be coupled with a positive feedback to allow the user and/or UE to gain a positive reputation even though a communication is marked as a potential UC. For example, a sender and/or sending UE may be associated with a negative score and/or be included on a blacklist, as described herein for example. The sender and/or sending UE may then want to leave the blacklist or gain a positive score. The sender and/or sending UE may receive positive points from a receiver and/or receiving UE, which may allow the sender and/or sending UE to restore the associated score.

[0092] The use of sender scorecards may not be influenced by IMS supplementary services, but IMS supplementary services may be enhanced by using sender scorecards. For example, by including a SC-V and/or a SC-P in front of any other supplementary services, the outcome of the verification of the received scorecard may be used to decide whether the incoming call is handled by further supplementary services (e.g., audio-captcha or consent- mailbox) or directly forwarded to the user.

[0093] If a user or domain operator defines target scores for a claim or claim category, an automatic score may be implemented based access control. This implementation may be used to populate blacklists (e.g., by automatically putting communication attempts with low scores on a blacklist).

[0094] Another option may be to define minimal scores for use of white lists. If a minimal score is reached, the communication may be established. In the case of a UC having a high-score, the user may put the caller on the blacklist. Such an implementation may be coupled with other actions, such as notification of issuing SC-I, automatic reduction of scores (e.g., in the reputation claims), and/or revocation of the scorecard for example.

[0095] In an embodiment using an Open Proxy Handshake protocol, scorecards may be included inside of issued tickets. The scorecards may be integrity protected (e.g., signed by a SC-I). If a sender in a sending domain uses the ticket to establish a communication session with a receiving domain, the scorecard may be sent into the receiving domain, evaluated by the receiving domain's SC-V, and the connection may be established based on the outcome of this assessment.

[0096] Scorecards may be used in permission based sending. By integrating scorecard functionality in the protocol level, it may be possible to authenticate a transaction, and based on the scores in the scorecard, the routers on the way may forward or drop packets.

[0097] The trustworthiness of a device or terminal may be determined based on integrity measures or other metrics, as described herein, for an authentication with a trusted network entity. The fact that the authentication between the device and network entity took place may be captured in a sender scorecard and the updated scorecard may be distributed freely by the network entity, the device, or other receiving entity to prove it's trustworthiness to other network entities. This trustworthiness may be accepted without the network entity having to perform another trust evaluation. The scorecard may also include supplementary information, such as the supplementary information described herein (e.g., device capabilities, security policies, and/or radio resource usage compliance policies it follows).

[0098] Scorecards may be used in connection with peer-to-peer communication networks. In a peer-to-peer communication network, a number of devices organized in a mesh may communicate with each other, for example, regarding spectrum utilization. Such devices may themselves be nodes in a hierarchical network (e.g., access points negotiating spectrum use for themselves and/or stations attached to them). In a cognitive spectrum network, a spectrum server may be accessed, which may provide information on an available spectrum. An example of such a network includes the approach to unlicensed use of TV spectrum (so-called TV White Spaces) currently proposed in the US and being considered in many other countries around the world. A device or network wishing to take advantage of the spectrum may contact a regulatory database that informs the station/network of the channels available in its location. The device/network may authenticate itself to the regulatory database and/or provide its location to obtain the channel availability information.

[0099] The proposed regulations (and/or the mandated database operation) make no mention of how unlicensed networks can coexist in the available channels. One possibility may be that the devices/networks may negotiate themselves and form a "network of networks" for the purpose of spectrum negotiation. While several architectures are possible for this network of networks (e.g., a coexistence server may be used), a peer-to-peer self-organizing mesh network may be a configuration that may be used. Member authentication in such a network may be a problem. For example, new entrants may have to prove that they or their network are legitimately who they say they are. The various members of such a spectrum management network may have access to various authentication server structures - but each to its own. As there may exist a distributed architecture, no common authentication infrastructure may be set up.

[0100] Scorecards may be used for authentication in such a network. Prior to beginning spectrum negotiation with other networks in the spectrum, each device/network may contact a spectrum management database and/or authenticate itself and/or its location. A spectrum management database may be well known and/or trusted (e.g., TVWS databases in the US may be operated under license and/or control by the FCC). Although such databases may not be setup to act as universal authenticators, authentication by one of them (e.g., if proven by a Trusted Environment) may be used to the same, or similar, effect.

[0101] In an exemplary implementation, proof of successful identity and/or location verification by a spectrum management database may be added to the scorecard. An exemplary scorecard may comprise identity properties for a mesh network (e.g., as described herein), location properties (e.g., location measurement information, location measurement validation information, and/or location measurement validation results), identity properties for a spectrum server 1 and/or a spectrum server 2 (if multiple spectrum servers are used), such as a binding to mesh identity that may be optional if different identities are used (e.g., identity binding information, identity binding measurement information, and/or an identity binding measurement result), an identity acceptance by the spectrum server (e.g., identity acceptance server response information, identity acceptance validation information, and/or identity acceptance validation results), and/or location acceptance by the spectrum server (e.g., location acceptance server response information, location acceptance validation information, and/or location acceptance validation results).

[0102] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.