embodiments of the present methods and apparatus will be described more fully hereinafter with reference to the accompanying drawings . fig1 shows virtualized entities in a body sensor network object ( bsno ). note that smartness can be embedded in different modules of bsno . the bsno can be a source of data to be stored in a personal data store ( pds ). fig2 presents an embodiment of an architecture for a pds . the pds collects , categorizes , stores , and offers application programming interfaces ( apis ) for appropriate access . the collection can be from both private and public interactions of a person with applications and services ( email , web access and browsing , etc . ), and with systems ( census , blogs , etc .). the maintenance , including archiving and categorization , can be based on different criteria . although further granularization is possible , personal data can be categorized into private , public , secret and top - secret as shown in fig2 . the access to the pds can be for pbb ( personal black box ) and other applications , and different apis can be utilized after appropriate ( embedded or on - demand ) authentication service . fig3 illustrates a high - level architecture of a network that uses bsnos . open server side and open client side apis are used , and no specialized apis are needed . embedded web services using light - weight versions of protocols like http , xml , json , and constrained application protocol ( coap ) are utilized depending on the foot - print , power budget , and capability requirements . vital monitoring cluster ( vmc ) based applications and services that run seamlessly and with low - memory and processing overhead are utilized for the purpose of smart body sensor object networking . for more detail on coap , please see the constrained application protocol ( coap ), ietf rfc 7252 , june 2014 , available at http :// www . rfc - editor . org / rfc / rfc7252 . txt , which is incorporated herein by reference in its entirety . fig4 depicts an architecture for clustering and virtual - ring based communication among body sensor objects ( bsos ), which may include smart body sensor objects ( sbsos ). bsos may use active radio - frequency identification ( rfid ) tags for identification and communication . however , each bso may in addition need another identifier for privacy and security reasons . based on a pre - specified and pre - programmed interface , each bso continuously or periodically logs sensed data in , for example , comma - separated value ( csv ) format . a bso may also receive input data from secondary and tertiary bsos that may be members of the same bso cluster group , via a clustermaster or clustervisor , as shown in fig4 ). the stored log data are processed in real - time to locate anomalies — threshold crossing and correlated events — and then uploaded to archive or to replenish the stored information . for example , a refined version of message queuing telemetry transport ( mqtt ) can be effectively utilized for automated local and remote status updating and trigger generation . where the bsos are monitoring the physiological status of the wearer &# 39 ; s body , for example , a trigger in response to an anomaly may send out an alarm , a call to a first - responder , etc .). for more detail on mqtt , please see “ message queuing telemetry transport ( mqtt ) for lightweight publish / subscribe messaging transport , 2014 , available at http :// mqtt . org /. fig5 shows a sequence of steps for collecting and processing the monitored data / information from the body sensors . additional modules and analyses can be easily utilized for anomaly detection and clustering - based discovery of abnormality in the monitored information streams . fig6 illustrates a sequence of steps to hinder unauthorized access to the information in the pds . in step 602 , the authentication client and proxy ( see fig2 ) receives from an entity a request for access to the stored data , or some of the stored data . in an embodiment , the request is received over the internet or other public network , and the authentication client initially does not know who or what the entity is . in step 604 , the authentication client requests at least one credential from the entity . for example , the authentication client may present a login screen requiring a username and password . in that case , the initial request may be implied by the entity accessing the login screen . in step 606 , the authentication client determines whether the at least one credential is determined to be correct for an entity authorized to access the data . if the at least one credential is correct , in step 608 the authentication client permits the entity to access the data . as is known , the authentication client may accept more than one different at least one credential , and may grant access to different parts of the data in the pds depending on the credential ( s ) accepted . for example , secret data may be accessible only to the owner of the data , while private data may be accessible to additional entities previously approved by the owner , or to classes of entity recognized as entitled to access that class of data . if at step 606 the at least one credential is not correct , in step 610 the authentication client determines whether a permitted number of trials has been exceeded . if the permitted number of trials has not been exceeded , in step 612 the authentication client adds a new credential to the request , and returns to step 604 . the new credential may be instead of or in addition to , the at least one credential previously requested . for example , if at the first attempt the login screen required only a username and password , at the second attempt the login screen may require a username , password , and some additional personal information or the previously agreed answer to a security question . this is in contrast to conventional login systems , where the login screen typically allows repeated attempts to present the same credentials , and answers to additional security questions are requested only if the entity trying to log in admits that he , she , or it is unable to provide the credentials originally requested . inviting the entity to present again ( and by implication to correct ) the original username and password , as well as answering the additional question , gives the appearance that the authentication client assumes the previous invalid credentials were an innocent error by a bona - fide user . if the authentication client in fact suspects that the entity is a hacker , that appearance can be useful in lulling the hacker into a false sense that he or it has not been detected . the process may loop through steps 604 , 606 , 610 , 612 several times , requiring a more difficult set of credentials each time . if at step 610 the permitted number of trials has been exceeded , the process branches to step 614 , assumes that the entity seeking access is a hacker or other unauthorized entity , and takes active countermeasures . for example , the authentication client may take active steps to trace from where the access request is originating . hackers often attempt to obscure their identity by sending their access requests from , or routing their access requests through , different source computers , but the hacker &# 39 ; s choice of computer or computers can still be informative . it is probably impossible to make any normal computer system truly hackproof , except by totally isolating the system . however , it is possible to make a system unhackable at the level that the cost ( in time , work , and commitment of resources that could have been used for some other purpose ) required to hack the system exceeds the value of the data obtained by hacking it . that is particularly true of the private data of ordinary people for the purposes of identity theft , where the value of the personal data is effectively determined by the cost of obtaining the most vulnerable personal data , so that the ordinary hacker can be effectively deterred by making the pds only moderately more secure than average .