Abstract: Systems and methods for managing umbilical lines and one or more jumpers are provided. An example of a system includes a deployment platform carrying a winch and spool assembly, a tether management assembly, and an integrated electrical and/or hydraulic umbilical line extending between a spool on the winch and spool assembly and the tether management assembly. The winch and spool assembly is configured to deploy and to support the umbilical line. The tether management assembly includes a winch and spool assembly for deploying a flying lead and/or annulus jumper adapted to connect to an emergency disconnect package of a well control package for a well. A set of buoyant modules are connected to or integral with a portion of the umbilical line to be used to form an artificial heave compensation loop.

Abstract: Some embodiments include a method of providing a semiconductor device. The method can include: (a) providing a flexible substrate; (b) depositing at least one layer of material over the flexible substrate, wherein the deposition of the at least one layer of material over the flexible substrate occurs at a temperature of at least 180° C.; and (c) providing a diffusion barrier between a metal layer and an a-Si layer. Other embodiments are disclosed in this application.

Abstract: Some embodiments include dual active layers for semiconductor devices. Other embodiments of related devices and methods are also disclosed.

Abstract: Systems and methods for managing umbilical lines and one or more jumpers are provided. An example of a system includes a deployment platform carrying a winch and spool assembly, a tether management assembly, and an integrated electrical and/or hydraulic umbilical line extending between a spool on the winch and spool assembly and the tether management assembly. The winch and spool assembly is configured to deploy and to support the umbilical line. The tether management assembly includes a winch and spool assembly for deploying a flying lead and/or annulus jumper adapted to connect to an emergency disconnect package of a well control package for a well. A set of buoyant modules are connected to or integral with a portion of the umbilical line to be used to form an artificial heave compensation loop.

Abstract: In some embodiments, a method of etching an organosiloxane dielectric material can include: (a) providing the organosiloxane dielectric material; (b) providing a patterned mask over the organosiloxane dielectric material; and (c) reactive ion etching the organosiloxane dielectric material. Other embodiments are disclosed in this application.

Abstract: Some embodiments include a method of providing a semiconductor device. The method can include: (a) providing a flexible substrate; (b) depositing at least one layer of material over the flexible substrate, wherein the deposition of the at least one layer of material over the flexible substrate occurs at a temperature of at least 180° C.; and (c) providing a diffusion barrier between a metal layer and an a-Si layer. Other embodiments are disclosed in this application.

Abstract: Described is a notifications platform that routes notifications to endpoints of recipients, corresponding to email, instant messaging, text messaging, telephones, social networks, blogs and/or the like. A publisher of a notification designates the recipients, while preference data of each recipient determines whether that publisher is able to send to that recipient, and if so, to which endpoints. The notification may be modified via one or more templates to be appropriate for a locale of the recipient, as well as appropriately formatted for the endpoint, which may also be locale-specific.

Abstract: In some embodiments, a method of etching an organosiloxane dielectric material can include: (a) providing the organosiloxane dielectric material; (b) providing a patterned mask over the organosiloxane dielectric material; and (c) reactive ion etching the organosiloxane dielectric material. Other embodiments are disclosed in this application.

Abstract: In some embodiments, a method of providing a semiconductor device can include: (a) providing a substrate; (b) depositing a first metal layer over the substrate; (c) spin-coating a first dielectric material over the first metal layer, where the first dielectric material includes an organic siloxane-based dielectric material; and (d) depositing a second dielectric material comprising silicon nitride over the first dielectric material. Other embodiments are disclosed in this application.

Abstract: An apparatus for and a method of an electronic middleware interface consisting of communication interfaces designed to transfer data between financial record keeping systems and new account opening applications is presented. A retirement savings plan (RSP) administrator computer server communicates via the electronic middleware communication interfaces to a Rollover Solutions Network (RSN) application computer server to communicate financial savings plan participant data. The RSN application computer server utilizes the participant data to contact a financial service provider (FSP) computer server to identify the participant retirement accounts for rollover purposes. Alternatively, the RSN application computer server can contact the FSP computer server to open a new retirement account.

Abstract: A system and method are provided, whereby data that is easily re-created is separated from data that is not easily re-created, such that the easily re-created data can be disposed of based on a variety of events and the not easily re-created data can be kept in its original state. In one aspect of the invention, such easily re-created data is disposed of based on a “panic button” being pushed by a computer system user, such as when a user becomes aware that some malware has infected the computer system. In other aspects of the invention, such data is disposed of every time the computer system boots up, or detects via its anti-virus program that some malware is present. In other aspects of the invention, the easily re-created data can be rolled back or rolled forward without affecting the non-easily re-created data.

Abstract: Dynamic run-time verification of a module which is loaded in memory (in whole or in part) for execution is enabled by using pre-computed portion-level verification data for portions of the module smaller than the whole (e.g. at the page-level). A portion of the module as loaded into memory for execution can be verified. Pre-computed portion-level verification data is retrieved from storage and used to verify the loaded portions of the executable. Verification data may be, for example, a digitally signed hash of the portion. Where the operating system loader has modified the portion for execution, the modifications are reversed, removing any changes performed by the operating system. If the portion has not been tampered, this will return the portion to its original pre-loaded state. This version is then used to determine validity using the pre-computed portion-level verification.

Abstract: In order to allow for security beyond revocation lists, a policy regarding when permissions may be granted (in the form of a rights document, e.g. a use license or a certificate) is enforced. When a request is made for a rights document, the requester submits an account certificate which includes certain metadata regarding the requester. This metadata is analyzed to determine whether it meets a specific policy before the request is granted. If the request is not granted, the cause of the rejection may be overcome, for example by updating or upgrading some system component (hardware or software) in the requesting system. In certain cases, such an update to overcome a policy-based rejection may be performed transparently to the user.

Abstract: In order to prevent analysis by static and dynamic disassembly techniques, instruction level code obfuscation is performed to induce misalignment and mistaken analysis by disassemblers. Misalignment is induced by including a bypass which leads, during execution, to a legitimate location. During analysis, however, bogus data may be analyzed by the disassembler due to the bypass. Run-time modifications may also be included in code. Code is changed to an invalid state, and instructions inserted into the code which will return the code to a valid state during execution. During analysis, these invalid states may be analyzed by the disassembler as invalid instructions. Induced misalignments and run-time modifications can be chained together to produce sequences of code that will always produce invalid disassembly output from common disassemblers.

Abstract: Run-time call stack verification is used to determine that a code module has been called by a legitimate caller. A return address on the stack indicates where execution is to return upon execution of the next return instruction, and this return address is indicative of where the code module was called from. The code module may determine that the call is allowed, or disallowed, based on the location of the return address. A calling convention is provided that allows the code module to be called through an intermediary, while also preserving the original return address that was in effect at the time the intermediary was called and also resisting modification to the call stack during the time that the original return address is being verified.

Abstract: Dynamic run-time verification of a module which is loaded in memory (in whole or in part) for execution is enabled by storing hashes of smaller portions of the module (e.g. page-level hashes) as they should look when loaded into memory for execution. After an initial authentication is completed, hashes of smaller portions of the module are stored. These hashes consist of the portion of memory as modified by changes which would be made by the operating system loader operating normally. Thus, the hashes can be used to verify that the portion as loaded into memory for execution is 1) a correct copy of the portion of the software module, 2) correctly modified for execution by the processor, and 3) not tampered with since loading.

Abstract: The import address table of a software module is verified in order to prevent detouring attacks. A determination is made regarding which entries in the IAT must be verified; all of the entries may be verified or some subset of the entries that are critical may be verified. For each external function, the external module containing the external function is loaded, if it is not already loaded. The function address in the exported function table is found. That address is compared to the address for the function in the IAT. Additionally, the external module, in one embodiment, is verified to ensure that it has not been modified. For a delay load IAT, a similar procedure is followed; however the delay load IAT may be periodically checked to ensure that the delay load IAT entries are either valid (indicating that the external function has been bound) or in their initial state (indicating that no binding has yet occurred).

Abstract: Additional code is added to sensitive code in order to foil an adversary attempting to examine or modify the sensitive code. The additional code implements a cascade failure system. In the cascade failure system an intrusion is detected by an authorization check, and when an intrusion is detected, further changes are made which will trigger failures of other authorization checks or cause corruptions to the internal execution state of the program. Eventually, the changes will trigger a complete failure of the code to run correctly, however the genesis of the cascading failure will be concealed, so an adversary will not be able to determine how the intrusion was initially detected. The insertion of the additional cascade failure system code can be performed automatically by a mechanism with some random components, and thus the locations and content of the inserted code may be different for each instance of sensitive code into which a content failure system has been inserted.

Abstract: The execution of software may be controlled by a security policy expressed in a manifest. The software vendor or distributor specifies requirements for the use of software (e.g., which modules may be loaded into the software's address space, which module-signing keys are trustworthy, etc.), using a manifest specification language. A generation tool reads the specification and creates a manifest based on the specification. The tool may handle such details as retrieving keys from key files, computing software hashes, and the like. The manifest is distributed with the software and used by the environment in which the software executes to enforce the security policy.