fig2 is a schematic diagram of a system 200 for providing software object - level behavioral control on a surface based computing device 210 that can vary based upon a set of users 205 proximate to the surface based computing device 210 . a surface based computing device 210 can employ the use of a multi - touch sensitive display to interact with one or more users 205 . interactions can occur through an approximately horizontal computing surface , which is able to function as a table or similar surface . system 100 shows an example of one contemplated surface based computing device 210 . the device 210 can execute a set of applications 216 , which perform computing operations 218 involving software objects 234 . these software objects 234 can be stored in a data store 230 accessible by the computing device 210 . permitted software object 234 behavior can be defined on a per - object basis using behavior tokens 236 . for example , the behavior tokens 236 can specify a set of operations 218 , which are allowed to be performed against one or more software objects 234 associated with the token 236 , can impose restrictions on these operations 218 , and can define conditions that change the permitted operations 218 . controllable object behavior can include whether an object 234 can be read , copied , deleted , or edited . behavior can also be operation 218 specific . behavioral restrictions can , for example , impose a limit on an amount of zoom permitted or on a viewing resolution permitted against an image ( one type of software object 234 ). different types of software objects 234 can have different behavioral restrictions suitable for that type . for example , a playback duration restriction and a playback quantity restriction can be behavioral restrictions placed upon a video or music software object 234 . in another example , a print restriction can be imposed on a photograph or document object 234 . an object behavior engine 220 can enforce behavior restrictions for objects 234 as defined by the behavior tokens 236 . identities of users 205 proximate to the computing device 210 can be one of the conditions that change which operations are permitted against one or more software objects 234 . that is , authorized behavior can vary based upon an identity of a set of users 205 proximate to the computing device 210 . user detector 214 can automatically detect users 205 proximate to device 210 and can fire user change events . user change events can indicate when new users 205 approach within a defined distance of device 210 and / or when users 205 previously within an interactive range of device 210 , leave this range . in one embodiment , a concept of a device usage state can be used to minimize complexities associated with behavior related actions that vary based upon user 205 proximities to device 210 . in other words , behavior permitted against software objects 234 can depend upon which users 205 are accessing the software objects 234 , upon whether software object 234 manipulations are being supervised by a responsible user 205 , upon whether any unauthorized bystanders are able to observe the object 234 manipulations , and other definable factors . illustrative device usage states can include an owners only state , an administrator only state , an administrator and consumer state , a consumer only state , an intruder state , etc . to elaborate , the owners only state can be a state when the only user ( s ) 205 proximate to device 210 own the object 234 being evaluated . the administrator only state can be a state where all users 205 proximate to device 210 have administrator privileges for the object 234 being evaluated . the administrator and consumer state can indicate that users 205 proximate to device 210 have at least consumer privileges and that one of the users 205 proximate to device 210 has at least administrator privileges . the consumer only state can indicate that all users 205 proximate to device 210 have consumer privileges . the intruder state can indicate that one user 205 proximate to device 210 has no privileges for the object 234 being evaluated . different permissible behaviors for an object 234 can be specified by the behavior token 236 per device usage state . for example , when a graphic object 234 is used in an owners only state no restrictions may be applied . when the same graphic is used in an administrator and consumer state , a zoom restriction can be applied so that the graphic can only be zoomed to a defined level . in a consumer only state , zoom features for the graphic object can be disabled and the graphic object can only be displayed at a limited resolution . in an intruder state , the graphic object may not be displayable . it should be emphasized that different objects 234 can be associated with different behavior tokens 236 , which specify different behavioral restrictions . changing device usage states can be a dynamic process based upon user 205 proximity to device 210 , which is performed by the user detector 214 . method 240 is a flow chart showing this dynamic process . method 240 can include a step 242 , where a check for changes to surface users ( users 205 ) can be conducted . when no change is users is detected , step 242 can repeat after a suitable delay or until an event associated with a possible change in user proximity occurs . when the users 205 proximate to device 210 change , an identity of the users 205 proximate to the device 210 can be determined , as shown by step 244 . this step can involve comparing user specific characteristics , such as a user identifier entered into device 210 or a biometric captured by device 210 , against a maintained data store of characteristics , which can be indexed against user permissions . user permissions can indicate a general usage category of a user , such as customer , sales representative , software developer , unknown , and the like . the usage category for a single user 205 can vary based upon usage context , such as which application 216 is being used , which software object 234 is being manipulated , and the like . after a usage category is determined per proximate user 205 , a set of configurable rules can be accessed , which determine a device usage state given the set of users 205 proximate to the device 210 and the general categories to which the users are associated . the device usage state can be changed in step 246 to reflect the current set of users 205 proximate to device 210 . the method 240 can be a dynamic and constantly changing one , which is shown by the method looping from step 246 back to step 242 , where another check for a change in proximate users can be made . an asynchronous process 250 performed by object behavior engine 220 can adjust behavior settings of the objects 234 based at least in part upon a current device usage state . method 250 can begin in step 252 , where a programmatic event relating to a use of a software object 234 by an application 216 executing on device 210 can be detected . an identity of a user 205 who is attempting to use the object 234 can be determined , as shown by step 254 . in step 256 , a determination can be made from permissions specified within a related token 236 concerning which permissions are to be granted for the software object 234 given a current device usage state . in step 258 , a usage request for the object 234 can be approved or denied based upon results of step 256 . in step 260 , suitable programmatic actions can be performed based upon the approval decision . it should be appreciated that application 216 , engine 220 , and detector 214 can each include a set of software / firmware instructions stored in a machine readable medium which cause hardware components of device 210 to perform a set of actions , when the instruction code executes . different , valid computer science techniques can be used by one of ordinary skill in the field to implement this hardware / software combination so long as an overall effect is achieved consistent with that described herein for application 216 , engine 220 , and detector 214 . for example , any number of different programming techniques can be used to implement the behavioral restrictions specified within the behavioral tokens 236 for the software objects 234 . in one embodiment , application 216 code can be specifically modified to only allow those operations 218 permitted by the behavioral token 236 . in another embodiment , software can intercept programmatic calls involving the software object 234 , object approval actions involving engine 220 can be taken , and intercepted calls can be permitted or denied based upon approval results . numerous call interception techniques exist that can be adapted for system 200 , many of these techniques are used currently for tracking usage of in - place software without modifying that software . although the behavior tokens 236 are shown as being distinct from the software objects 234 this need not be the case . that is , in one contemplated embodiment , the behavior tokens 236 can be integrated within the software objects 234 , such as meta data of the software objects 234 to which they relate . this meta data can keep track of properties such as : ownership , access rights for others , all behavioral capabilities ( e . g ., zoom in and out , copy , modify to be enabled / disabled / partially enabled , etc .) and object changes for different device usage states . the software tokens 236 can include data storage areas or fields , which are updated as system 200 is used . for example , when a software object 234 can have defined restrictions related to playback duration or quantity , updatable fields relating to playback duration or quantity can exist within the related token 236 . in one embodiment , a default set of behavioral tokens 236 can be established that define usage behavior restrictions for software objects 234 . object specific settings can override the default object behaviors . additionally , different groups of software objects 234 can be optionally established , and behavior tokens 236 can be established that define group - level behavior . any level of tiered behavioral groupings can be established , where more specific settings are able to override more generic settings . similarly , it is contemplated that even when device usages states are used to reduce complexities involving user 205 specific permissions , user 205 specific overrides can be established for system 200 that permit a finer grained control of object behavior that varies based upon a proximate set of users 205 . generally , system 200 illustrates a concept of object - level behavioral control within a surface based computing setting , which can vary based upon a set of proximate users 205 . an arbitrary level and complexity of programmatic control can be imposed , so long as deterministic rules ( optionally configurable ) can define usage behavior restrictions and relationships between object behavioral rights and proximate sets of users 205 . fig3 is a schematic diagram 300 of a surface based computing device 305 having software object level permissions in accordance with an embodiment of the inventive arrangements disclosed herein . the surface based computing device 305 can be an implementation instance of device 210 . the surface based computing device 305 can include hardware 310 and software 340 . hardware 310 can include the necessary components to create the functionality of a surface based computing device 305 , such as a display surface 315 , infrared projectors 320 , display projector 325 , processing unit 330 , tag scanner 332 , biometric reader 334 , and / or other components . the display surface 315 can be used with infrared projectors 320 to detect movements and objects placed upon the surface 315 . the display projectors 325 can product visible images upon the display surface 315 for users 370 to view . the processing unit 330 can execute programmatic instructions 330 and can manage the other components 315 , 320 , 325 , 332 - 334 of the device 305 . tag scanner 332 can read information from detection tags 327 , which is one means for determining a presence and identity of users 370 . the biometric reader 334 can capture a user characteristic ( e . g ., picture , finger print , iris scan , voice , etc .) that is processed to determine a user &# 39 ; s identity . software 340 can include programmatic instructions executable by hardware 310 that permits the device 305 to function . software 340 can include an object behavior engine 350 , as described previously ( engine 220 ). the presence detection engine 345 can be the software component for performing functions attributed to the user detector 214 . more specifically , engine 345 can utilize a variety of presence detection software techniques and technologies to determine ( from input provided via scanner 332 , reader 334 , and other detection hardware ) a set of users 370 that are proximate to device 305 . in one embodiment , for example , users 370 can carry a detection tag 372 , which is readable by scanner 332 . for example , tag 372 can be a radio frequency identification ( rfid ) tag , a bluetooth device , a wifi transceiver , or other component that is able to convey digital information concerning the user 370 and the user &# 39 ; s presence to device 305 . digitally encoded content used by device 305 can be stored in a data store 355 . for example , data store 355 can store software 340 , can store software objects and behavior tokens , and can store rules for applying object - level security . as shown , an object token table 360 can record relationships between objects and behavioral tokens . one - to - one relationships can exist , as shown by image 1 being associated with token a , image 2 being associated with token b , and document 1 being associated with token c . a behavioral token can also apply to a group of software objects of a particular type , as shown by document 2 being associated with a document token . when an object is not specifically associated with any behavioral token , a default token can be applied to the software object , as shown by document 3 being associated with default token . data store 355 can also include a user group table 380 . the table 380 can include a user identifier column , a context column , a permission group column , a biometric column , a security key column , and the like . values in the biometric and security key columns can be compared against input obtained form the biometric reader 334 and scanner 332 to determine a user &# 39 ; s identity . the same user can belong to different permission groups , depending upon an evaluation context . for example , in the context of a company abc software object , user a belongs to an administrator group . in the context of a company def object , user a can belong to a consumer group . a token behavior table 390 can also be stored in data sore 355 , which can be used to associate tokens , device usage states , and object behaviors . device usage states can be determined from the permission groups of users 370 detected near the device 305 . a single token can permit different behaviors depending upon a current device usage context . as shown , token a grants full behavioral permissions ( behavior aa ) for a device usage state of owners only . specifics of token a for a consumers only state results in restrictions on image zoom , copy , and image resolution ( behavior ab ). as used herein data store 355 can be physically implemented within any type of hardware including , but not limited to , a magnetic disk , an optical disk , a semiconductor memory , a digitally encoded plastic memory , a holographic memory , or any other recording medium . data store 355 can be stand - alone storage units as well as a storage unit formed from a plurality of physical devices , which may be remotely located from one another . additionally , information can be stored within the data store 355 in a variety of manners . for example , information can be stored within a database structure or can be stored within one or more files of a file storage system , where each file may or may not be indexed for information searching purposes . fig4 illustrates a few scenarios 410 , 430 , and 450 for controlling software object behavior based in part upon a presence of users about a surface based computing device . the scenarios 410 , 430 , and 450 can occur in the context of a system 200 . in scenario 410 , two users 412 and 414 can be interacting with software objects 426 , 427 , and 428 using surface based computing device 416 . the users 412 , 414 can both have administrator privileges against the software objects 426 - 428 , which places the device 416 in an administrator only device usage state within which zooming 422 and editing 423 capabilities are enabled for the objects 426 - 428 . a bystander 413 , who lacks permissions to use objects 426 - 428 , can approach the device 416 . in response , the zooming 422 and editing 423 capabilities can be disabled and the software objects 426 - 428 can be hidden . these adjustments are made in accordance with details specified for the objects 426 - 428 by behavior tokens . scenario 410 can represent a situation where sensitive information is presented within objects 426 - 428 , which should be protected from observations of non approved individuals ( e . g ., user 413 ). in scenario 430 , three users 432 , 434 , and 436 can utilize objects 441 - 444 on surface based computing device 438 . user 436 can be considered an administrator and users 432 and 434 can be considered consumers . when a device 438 is in an administrator and consumer usage state , access can be granted to all objects 441 - 444 . should the user 436 leave the area proximate to device 438 , the usage state can change to a consumer only state . as shown , access can still be maintained for objects 441 , 443 - 444 when in a consumer only state . access to object 442 can be blocked or limited . in scenario 450 , two users 454 and 456 can use objects 466 - 468 on surface based computer device 458 . possible operations able to be performed against the objects 466 - 468 can include magnifying or zooming via control 462 and editing via control 463 . object 466 can initially have focus , which causes behavioral adjustments to be made on surface 458 for object 466 . as shown , users 454 and 456 can be permitted to use the zoom control 462 but can be denied use of the edit control 463 for object 466 based upon privileges established by an associated behavior token . if the set of users 454 , 456 proximate to device 458 were to change , permission for object 466 can change in a corresponding fashion . should a user 454 , 456 select a different software object 467 , behavioral adjustments can be made on surface based computing device 458 for that object 467 in accordance with a behavioral token associated with object 467 . as shown , the zoom control 462 can be disabled for object 467 , but the edit control 463 can be enabled . again , changes to the set of users 454 , 456 about the device 458 can affect usage permissions for objects 466 - 468 . thus , scenario 450 is provided to emphasize that behavioral controls for software objects 466 - 468 are applied at an object level and can vary from object to object . the present invention may be realized in hardware , software or a combination of hardware and software . the present invention may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems . any kind of computer system or other apparatus adapted for a carrying out methods described herein is suited . a typical combination of hardware and software may be a general purpose computer system with a computer program that , when being loaded and executed , controls the computer system such that it carries out the methods described herein . the present invention also may be embedded in a computer program product , which comprises all the features enabling the implementation of the methods described herein , and which when loaded in a computer system is able to carry out these methods . computer program in the present context means any expression , in any language , code or notation , of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following : a ) conversion to another language , code or notation ; b ) reproduction in a different material form .