Abstract: This disclosure concerns systems and methods for tracking participation in meetings and managing conference rooms. A participation object may be used. The participation object may include an intended participation status and real-time participation status for each invitee to a meeting. The intended participation statuses may indicate whether each invitee intends to participate in the meeting and how each invitee intends to participate in the meeting. The intended participation statuses may be updated based on responses to meeting invitations. The real-time participation statuses may indicate whether each invitee is currently participating in the meeting and how each invitee is currently participating in the meeting. The real-time participation statuses may be updated based on check-ins. The check-ins may be received close to a start time of the meeting and during the meeting. The participation object may also include a meeting summary. The meeting summary may summarize participation in the meeting.

Abstract: Architecture for generating a temporary account (e.g., an email address) with a user-supplied friendly name and a secret used to the sign the temporary account. For example, when a user wishes to create a temporary email address to use with an online organization, a friendly name is provided and the system generates a temporary email address including the friendly name. A signing component signs the temporary email address with a secret. One or more of these secrets can be provisioned prior to the user's creation of a friendly name, which eliminates propagation delay. During use, only incoming email messages having the temporary email address signed with the secret are validated. When the user revokes the temporary email address, the secret is revoked and the revocation is propagated to network gateways, rejecting any email sent to that address.

Abstract: Architecture for generating a temporary account (e.g., an email address) with a user-supplied friendly name and a secret used to the sign the temporary account. For example, when a user wishes to create a temporary email address to use with an online organization, a friendly name is provided and the system generates a temporary email address including the friendly name. A signing component signs the temporary email address with a secret. One or more of these secrets can be provisioned prior to the user's creation of a friendly name, which eliminates propagation delay. During use, only incoming email messages having the temporary email address signed with the secret are validated. When the user revokes the temporary email address, the secret is revoked and the revocation is propagated to network gateways, rejecting any email sent to that address.

Abstract: Email-based recovery actions may be provided. A request from a user to perform an action may be received. If the user is determined not to have permission to perform the action, a message may be sent to a second user to approve the requested action. If the second user approves the requested action, the requested action may be performed.

Abstract: Architecture for generating a temporary account (e.g., an email address) with a user-supplied friendly name and a secret used to the sign the temporary account. For example, when a user wishes to create a temporary email address to use with an online organization, a friendly name is provided and the system generates a temporary email address including the friendly name. A signing component signs the temporary email address with a secret. One or more of these secrets can be provisioned prior to the user's creation of a friendly name, which eliminates propagation delay. During use, only incoming email messages having the temporary email address signed with the secret are validated. When the user revokes the temporary email address, the secret is revoked and the revocation is propagated to network gateways, rejecting any email sent to that address.

Abstract: Architecture for generating a temporary account (e.g., an email address) with a user-supplied friendly name and a secret used to the sign the temporary account. For example, when a user wishes to create a temporary email address to use with an online organization, a friendly name is provided and the system generates a temporary email address including the friendly name. A signing component signs the temporary email address with a secret. One or more of these secrets can be provisioned prior to the user's creation of a friendly name, which eliminates propagation delay. During use, only incoming email messages having the temporary email address signed with the secret are validated. When the user revokes the temporary email address, the secret is revoked and the revocation is propagated to network gateways, rejecting any email sent to that address.

Abstract: A multi-level monitoring system is provided for monitoring multiple performance aspects of a cloud service concurrently in order to generate a full and reliable performance analysis of the cloud service. The multi-level monitoring system may include a set of components for carrying out the performance analysis of the cloud service which may be deployed together to operate externally, internally, or concurrently with the cloud service. The component framework of the multi-level monitoring system may include a main component, a plug-in associated with the main component, a definition database, a log database, and an output database. The main components of an example multi-level monitoring framework may include a probe runner component for probing the cloud service, a monitor component for generating alerts based on probe results, and a responder component for processing the alerts and taking appropriate actions to improve the cloud service performance.

Abstract: A multi-level monitoring system is provided for monitoring multiple performance aspects of a cloud service concurrently in order to generate a full and reliable performance analysis of the cloud service. The multi-level monitoring system may include a set of components for carrying out the performance analysis of the cloud service which may be deployed together to operate externally, internally, or concurrently with the cloud service. The component framework of the multi-level monitoring system may include a main component, a plug-in associated with the main component, a definition database, a log database, and an output database. The main components of an example multi-level monitoring framework may include a probe runner component for probing the cloud service, a monitor component for generating alerts based on probe results, and a responder component for processing the alerts and taking appropriate actions to improve the cloud service performance.

Abstract: Email-based recovery actions may be provided. A request from a user to perform an action may be received. If the user is determined not to have permission to perform the action, a message may be sent to a second user to approve the requested action. If the second user approves the requested action, the requested action may be performed.

Abstract: Some embodiments provide techniques for determining a set of Abbe's kernels which model an optical system of a photolithography process. During operation, the system can receive optical parameters (e.g., numerical aperture, wavelength, etc.) for the photolithography process's optical system. Next, the system can use the optical parameters to determine a point spread function for an Abbe's source. Note that the point spread function for the Abbe's source can be determined either by discretizing the optical system's light source using a set of concentric circles, or by discretizing the optical system's light source in an orthogonal fashion. The system can then determine a correlation matrix from the point spread function. Next, the system can determine the set of Abbe's kernels by performing an eigen decomposition of the correlation matrix using principal component analysis. The system can then use the set of Abbe's kernels to compute image intensity.

Abstract: Some embodiments provide techniques for determining a set of Abbe's kernels which model an optical system of a photolithography process. During operation, the system can receive optical parameters (e.g., numerical aperture, wavelength, etc.) for the photolithography process's optical system. Next, the system can use the optical parameters to determine a point spread function for an Abbe's source. Note that the point spread function for the Abbe's source can be determined either by discretizing the optical system's light source using a set of concentric circles, or by discretizing the optical system's light source in an orthogonal fashion. The system can then determine a correlation matrix from the point spread function. Next, the system can determine the set of Abbe's kernels by performing an eigen decomposition of the correlation matrix using principal component analysis. The system can then use the set of Abbe's kernels to compute image intensity.

Abstract: Architecture for generating a temporary account (e.g., an email address) with a user-supplied friendly name and a secret used to the sign the temporary account. For example, when a user wishes to create a temporary email address to use with an online organization, a friendly name is provided and the system generates a temporary email address including the friendly name. A signing component signs the temporary email address with a secret. One or more of these secrets can be provisioned prior to the user's creation of a friendly name, which eliminates propagation delay. During use, only incoming email messages having the temporary email address signed with the secret are validated. When the user revokes the temporary email address, the secret is revoked and the revocation is propagated to network gateways, rejecting any email sent to that address.