Abstract:
A method and system for data record management is provided. In an embodiment, a method is provided for updating a data record representing a calendar appointment. The method comprises steps for inputting and saving data representing linked appointments that are associated with data representing base appointments.

Description:
FIELD 
       [0001]    The present specification relates generally to computer science and more specifically relates to a method and system for data record management in a computing device. 
       BACKGROUND 
       [0002]    The proliferation of computing devices is corresponding with ever increasing demands for functionality, which is further increasing demand for elegant and efficient management of data records within those devices and over communication networks that connect those devices with servers. The applications that are maintained and executable by such devices interact with large and complex databases, which contain unique records on different devices. Certain records maintained in those databases are often maintained in a disjointed fashion, hampering efficient operation of the device and consuming precious network bandwidth. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0003]      FIG. 1  is a schematic representation of a system for managing records in a computing device. 
           [0004]      FIG. 2  is a block diagram of the device shown in  FIG. 1 . 
           [0005]      FIG. 3  is a representation of a data structure for a calendar appointment record that can be stored in non-volatile storage of the device of  FIG. 2 . 
           [0006]      FIG. 4  shows a variation on the data structure of  FIG. 3 . 
           [0007]      FIG. 5  shows a flowchart depicting a method of data record management. 
           [0008]      FIG. 6  shows an exemplary graphical interface representation of a day view of a calendar entry generated on the display of the device of  FIG. 2 . 
           [0009]      FIG. 7  shows an exemplary representation of a graphical interface for receiving data representing a calendar appointment for storage in a calendar appointment record. 
           [0010]      FIG. 8  shows the graphical interface of  FIG. 7  wherein exemplary data has been inputted into the graphical interface. 
           [0011]      FIG. 9  shows a flowchart depicting a method of generating a graphical interface. 
           [0012]      FIG. 10  shows a graphical interface of  FIG. 6  after performance of the method in  FIG. 9 . 
           [0013]      FIG. 11  shows the graphical interface of  FIG. 8  wherein a data has been modified from the exemplary data shown in  FIG. 8 . 
           [0014]      FIG. 12  shows the graphical interface of  FIG. 10  after performance of the method in  FIG. 9  based on the data provided according to  FIG. 11 . 
           [0015]      FIG. 13  is a schematic representation of a system for managing records in a computing device. 
           [0016]      FIG. 14  shows a flowchart depicting another method of data record management. 
           [0017]      FIG. 15  shows a graphical interface to implement method the method in  FIG. 14 . 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0018]    An aspect of this specification provides a method for managing a data record comprising: 
         [0019]    receiving a request respective to a data record for a calendar appointment; the request comprising at least one of creating and modifying the data record; 
         [0020]    receiving data representing base appointment details for the data record; 
         [0021]    receiving data representing linked appointment details for the data record; 
         [0022]    storing the base appointment details and the linked appointment details in the data record. 
         [0023]    Another aspect of this specification provides a method for controlling an computing device: 
         [0024]    receiving a request to generate the graphical interface; 
         [0025]    determining a time and date range to be used in generating the graphical interface; 
         [0026]    retrieving a data record corresponding to the time and date range; the data record comprising base appointment details and linked appointment details; and 
         [0027]    generating the graphical interface; the graphical interface comprising a representation of the base appointment details and the linked appointment details. 
         [0028]    Referring now to  FIG. 1 , a system for managing records in a computing device is indicated generally at  50 . In a present embodiment system  50  comprises a first computing device in the form of a computing device  54  and a second computing device in the form of a server  58 . A network  66  interconnects each of the foregoing components. A first link  70  interconnects computing device  54  with network  66 . A second link  74  interconnects server  58  with network  66 . 
         [0029]    Computing device  54  can be any type of electronic device that can be used in a self-contained manner and to interact with content available on network  66 . Computing device  54  is operated by a user U. Interaction includes displaying of information on computing device  54  as well as to receive input at computing device  54  that can in turn be sent back over network  66 . Computing device  54  will be explained in greater detail below. 
         [0030]    Server  58  can be based on any well-known server environment including a module that houses one or more central processing units, volatile memory (e.g. random access memory), persistent memory (e.g. hard disk devices) and network interfaces to allow server  58  to communicate over network  66 . For example, server  58  both can be a Sun Fire V480 running a UNIX operating system, from Sun Microsystems, Inc. of Palo Alto Calif., and having four central processing units each operating at about nine-hundred megahertz and having about sixteen gigabytes of random access memory. However, it is to be emphasized that this particular server is merely exemplary, and a vast array of other types of computing environments for server  58  is contemplated. 
         [0031]    It should now be understood that the nature of network  66  and links  70  and  74  associated therewith is not particularly limited and are, in general, based on any combination of architectures that will support interactions between computing device  54  and server  58 . In a present embodiment network  66  itself includes the Internet as well as appropriate gateways and backhauls to links  70  and  74 . Accordingly, the links  70  and  74  between network  66  and the interconnected components are complementary to functional requirements of those components. 
         [0032]    More specifically, in a present embodiment system  50  includes link  70  between computing device  54  and network  66 . Link  70  is based, in a present embodiment, on core mobile network infrastructure (e.g. Global System for Mobile communications (“GSM”); Code Division Multiple Access (“CDMA”); CDMA 2000; 3G) or on wireless local area network (“WLAN”) infrastructures such as the Institute for Electrical and Electronic Engineers (“IEEE”) 802.11 Standard (and its variants) or Bluetooth or the like or hybrids thereof. Note that in an exemplary variation of system  50  it is contemplated that computing device  54  could be other types of computing devices whereby link  70  is a wired connection. System  50  also includes link  74  which can be based on a T1, T3, O3 or any other suitable wired or wireless connection between server  58  and network  66 . 
         [0033]    In a present embodiment, computing device  54  is a mobile electronic device with the combined functionality of a personal digital assistant, a cell phone, and an email paging device. Many well known cellular telephone models, or variants thereof, are suitable for the present embodiment. Referring now to  FIG. 2 , a schematic block diagram of device  54  is shown. It should be emphasized that the structure in  FIG. 2  is purely exemplary, and contemplates a device that be used for both wireless voice (e.g. telephony) and wireless data (e.g. email, web browsing, text) communications. Device  54  includes a plurality of input devices which in a present embodiment includes a keyboard  100 , a pointing device  102 , and a microphone  104 . Pointing device  102  can be implemented as a track wheel, trackball or the like. Other input devices, such as a touch screen are also contemplated. Input from keyboard  100 , pointing device  102  and microphone  104  is received at a processor  108 . Processor  108  is configured to communicate with a non-volatile storage unit  112  (e.g. Erase Electronic Programmable Read Only Memory (“EEPROM”), Flash Memory) and a volatile storage unit  116  (e.g. random access memory (“RAM”)). Programming instructions that implement the functional teachings of device  54  as described herein are typically maintained, persistently, in non-volatile storage unit  112  and used by processor  108  which makes appropriate utilization of volatile storage  116  during the execution of such programming instructions. Variants on device  54  can include a laptop computer or a desktop computer. 
         [0034]    Processor  108  in turn is also configured to control a speaker  120  and a display  124 . Processor  108  also contains a network interface  128 , which is implemented in a present embodiment as a radio configured to communicate over link  70 . In general, it will be understood that interface  128  is configured to correspond with the network architecture that defines link  70 . It should be understood that in general a wide variety of configurations for device  54  are contemplated. 
         [0035]    In a present embodiment, device  54  is also configured to maintain a calendar application  136  within non-volatile storage  112 . Processor  108  is configured to execute calendar application  136 , receive input from keyboard  100  relative to calendar application  136 , and to generate graphical interfaces on display  124  relative to calendar application  136 . Device  54  is further configured to maintain at least one database  138  comprising a plurality of data records  140  within non-volatile storage  112  respective to calendar application  136 . For convenience, only a single data record  140  is shown in  FIG. 2 . Processor  108  is configured, when executing calendar application  136 , to write updates to database  138  that correspond to inputs received via keyboard  100  or pointing device  102  or both. Updates to database  138  can comprise creation, deletion, and changes to data records  140 . Processor  108  is further configured, when executing calendar application  136 , to read data records  140  as part of generating graphical interfaces on display  124  respective to calendar application  136 . It will now be apparent to those of skill in the art that data records  140  each comprise data representative of a calendar appointment. 
         [0036]    Referring now to  FIG. 3 , an exemplary structure for data record  140  is provided in the form of an empty record  140 -A. Data record  140 -A comprises a plurality of fields  300 - 1 ,  300 - 2 ,  300 - 3 ,  300 - 4 ,  300 - 5 ,  300 - 6 ,  300 - 7 ,  300 - 8 ,  300 - 9  and  300 - 10 . (Generically, field  300  and collectively, fields  300 . This nomenclature is used elsewhere herein.) Field  300 - 1 , labeled “Subject”, represents the primary identifying information of the calendar appointment. Field  300 - 2 , labeled “Location” represents the particular location at which the calendar appointment will occur. Field  300 - 3 , labeled “All Day” is a flag which indicates whether or not the calendar appointment is to occur over the entire 24 hour period(s) associated with the date(s) of the calendar appointment. If field  300 - 3  is flagged as “yes”, then the aspects of fields  300 - 4 ,  300 - 5 ,  300 - 6  that relate to time will become inactive and only date related data, and no time-related data, will be entered for those fields. If, however, if Field  300 - 3  is flagged as “no”, then the aspects of fields  300 - 4 ,  300 - 5 , and  300 - 6  that relate to time will become active and both time and date data will be entered for those fields. Field  300 - 4 , labeled “start” represents data identifying the time, if appropriate, and date that the particular calendar appointment will commence. Field  300 - 5 , labeled “end”, represents data identifying the time, if appropriate, and date that the particular calendar appointment will finish. Field  300 - 6 , labeled “duration” represents a data identifying the time the difference between the time and date relative to field  300 - 5  and field  300 - 4 . (Note that device  54  can be configured, within calendar application  136 , to execute a process that verifies that the data in field of  300 - 5  and field  300 - 6  correspond and that such a process can be further configured to auto calculate either field of  300 - 5  or field  300 - 6  based on the contents of the other.) Field  300 - 7 , labeled “Show time as”, represents a flag that can be used to indicate whether the calendar appointment is to indicate that user U is “busy” or “not busy” (or other flag) as desired. Field  300 - 8 , labeled “Reminder”, represents a data identifying the duration (e.g., 5, 10, 15 minutes etc. . . . ) before the “start” time that the calendar application  136  is to remind the user U of the calendar appointment. Field the  300 - 9 , labeled “Recurrence”, represents an indication as to whether or not the calendar appointment has more than one instance. If the calendar appointments has a plurality of instances, then field  300 - 9  can be used to delineate a pattern for those instances. Field at  300 - 10 , labeled “appointment link”, is a flag that represents whether the present calendar appointment is linked to other calendar appointments. 
         [0037]    Referring now to  FIG. 4 , record  140 -B is shown. Record  140 -B is an alternative form of record  140 -A, wherein field  300 - 10  is completed with the flag “yes” instead of the flag “no”. Thus, when field  300 - 10  is completed with the flag “yes” then record  140  takes a slightly different form, as shown in  FIG. 4 . Record of  140 -B is an extended version of record  140 -A, in that record  140 -B includes at least the additional fields  300 - 11 ,  300 - 12 ,  300 - 13  and  300 - 14 . Field  300 - 11 , labeled “link name”, identifies the name of a specific linked calendar appointment that is linked to the calendar appointment associated with fields  300 - 1  through  300 - 9  of record  140 -B. Field  300 - 12 , labeled “Subject”, identifies the name of the linked calendar appointment. Field  300 - 13 , labeled “Start time”, identifies the time that the linked calendar appointment identified in field  300 - 12  commences. Field  300 - 14 , labeled “End time”, identifies the time that the linked calendar of identified in field  300 - 12  finishes. Those of skill in the art will now recognize that: the format of Field  300 - 12  can generally correspond to the format of Field  300 - 1 ; the format of Field  300 - 13  can generally correspond to the format of Field  300 - 4 ; and the format of Field  300 - 14  can generally correspond to the format of Field  300 - 5 . It is contemplated that record  140 -B can include additional linked calendar appointments whereby fields  300 - 11  through  300 - 14  are duplicated for each additional linked calendar appointment. 
         [0038]    Referring now to  FIG. 5 , a method for data record management is represented in the form of a flowchart and indicated generally at  500 . In a present embodiment, method  500  can be performed using device  54  but it is to be understood that variations on method  500  and device  54  are contemplated. 
         [0039]    When performed on device  54 , it is generally contemplated that calendar application  136  is being executed by processor  108  at the time of invocation of method  500 . Indeed, method  500  can be incorporated into calendar application  136 . 
         [0040]    Beginning at block  505 , a request is received relative to a data record for a particular calendar appointment. The request can be to create a new calendar appointment or to modify an existing calendar appointment. Such a request can be received at processor  108 , via input received from keyboard  100  or pointing device  102  or both.  FIG. 6  can assist in illustrating how the request at block  505  can be generated. In  FIG. 6 , a graphical interface  136 G is shown on display  124 . Graphical interface  136 G shows an empty calendar for the date Monday, Mar. 26, 2007. Graphical interface  136 G can be generated by processor  108  executing calendar application  136  so as to control display  124 . The time period of “1:00 p.m.” is shown as highlighted on graphical interface  136 G. Such highlighting can be effected via pointing device  102  interacting with programming instructions within calendar application  136  that are configured to be responsive to pointing device  102 . Further depression of, for example, the “enter” key on the keyboard  100  can ultimately complete performance of block  505 . Other means of effecting block  505  will now occur to those of skill in the art. 
         [0041]    Referring again to  FIG. 5 , at block  510 , base appointment details for a data record are received.  FIG. 7  shows an exemplary graphical interface  140 G-A that can be generated on display  124  as display  124  is controlled by processor  108  as part of performance of block  510 . Graphical interface  140 G-A is responsive to input from keyboard  100  or pointing device  102  or both to receive the inputs contemplated at block  510 . (Note that in  FIG. 7  no exemplary data is entered into fields  300 - 1  through  300 - 9 ;  FIG. 7  simply represents an exemplary “blank screen”.) 
         [0042]    At block  515 , a determination is made as to whether the data record is to be extended. A “no” determination is made if the flag in field  300 - 10  is set to “no”. If the determination at block  515  is “no” then method  500  advances to block  530  and the completed record  140  is saved in non-volatile storage  112  with only the data that has been in entered into fields  300 - 1  through  300 - 9 . 
         [0043]    However, if the flag in field  300 - 10  is set to “yes” then method  500  advances to block  520 . At block  520 , linked appointment details are received in the data record. Linked appointment details correspond to completion of fields  300 - 12 ,  300 - 13  and  300 - 14 . 
         [0044]      FIG. 8  shows an exemplary graphical interface  140 G-B that can be generated on display  124  as display  124  is controlled by processor  108  as part of performance of block  520 . Graphical interface  140 G-B shows graphical interface  140 G-A in its completed form as a result of input received from keyboard  100  or pointing device  102  or both, after both block  510  and block  520  have been completed. Graphical interface  140 G-B also reflects that a “yes” determination was made twice at block  515 , and so that linked appointment details were received for two different linked appointments at block  520 . Indeed, fields  300 - 12  through  300 - 14  on graphical interface  140 G-B reflect the first performance of block  520 , and fields  300 - 15  through  300 - 17  reflect the second performance of block  520 . Note that fields  300 - 15  though  300 - 17  are parallel in structure to fields  300 - 12  through  300 - 14 . 
         [0045]    Note, in particular that linked appointment number one, corresponding to fields  300 - 12  through  300 - 14  contain: the subject “Drive to Smithsville” in field  300 - 12 ; a start time of “1 Hour and 0 minutes Before” in field  300 - 13 ; and an end time of “0 hours and 0 minutes Before” in field  300 - 14 . The start time in field  300 - 13  thus represents that the linked calendar appointment number one will begin one hour prior to the start time indicated in Field  300 - 4 —in other words that linked appointment number one will begin on Monday Mar. 26, 2007 at 12:00 PM. The end time in field  300 - 14  thus represents that the linked calendar appointment number one will end at the start time indicated in Field  300 - 4 —in other words that linked appointment number one will end on Monday Mar. 26, 2007 at 1:00 PM. Note in a present embodiment that fields  300 - 13  and  300 - 14  are expressed in terms that are relative to the contents of field  300 - 4 , although in other embodiments they could be expressed, or maintained, in absolute terms. 
         [0046]    Note, also that linked appointment number two, corresponding to fields  300 - 15  through  300 - 17  contain: the subject “Drive back from Smithsville” in field  300 - 15 ; a start time of “0 minutes After” in field  300 - 16 ; and an end time of “1 hour and 0 minutes After” in field  300 - 17 . The start time in field  300 - 16  thus represents that the linked calendar appointment number two will begin exactly at the end time of indicated in Field  300 - 5 —in other words, linked appointment number two will begin on Monday Mar. 26, 2007 at 2:00 PM. The end time in Field  300 - 17  thus represents that the linked calendar appointment number two will end one hour after the end time indicated in Field  300 - 5 —in other words, linked appointment number two will end on Monday Mar. 26, 2007 at 3:00 PM. Note in a present embodiment that fields  300 - 16  and  300 - 17  are expressed in terms that are relative to the contents of field  300 - 5 , although in other embodiments they could be expressed, or maintained, in absolute terms. 
         [0047]    Having completed entry of data into graphical interface  140 G-B as shown in  FIG. 8 , and referring again to  FIG. 5 , a determination will be made at block  515  that no further record extensions are to occur and method  500  will advance to block  530 . At block  530  data entered into graphical interface  140 G-B will be saved as record  140  in non-volatile storage  112 . 
         [0048]    Referring now to  FIG. 9 , a method for generating a graphical interface is presented in the form of a flowchart and indicated generally at  900 . To assist in the explanation of method of  900 , it will be assumed that method  900  is performed by device  54  and that record  140  contains the data as shown in  FIG. 8 . Method  900  can be a process that is incorporated into calendar application  136 . 
         [0049]    At block  905  a request is received to generate a graphical interface. In the present example the request will be to generate a graphical interface according to a single day view within calendar application  136 . At block  910  a determination is made as to the requested time and date range to be generated on the graphical interface. In the present example, the time and date range will be between 10 a.m. and 5 p.m. on Monday, Mar. 26, 2007. (Note that, the means by which the time and date range are determined is not particularly limited and can be based on, for example, the default time range for a selected date, in this case the selected date being Monday, Mar. 26, 2007.) 
         [0050]    At block  915  a record is retrieved corresponding to the time and date range determined at block  910 . Continuing with the present example, record  140 , which includes the contents from  FIG. 8 , is retrieved from non-volatile storage  112 . 
         [0051]    At block  920  an interface is generated that includes the base appointments details. In the present example, the base appointments details include the data found within fields  300 - 1  through  300 - 9  of  FIG. 8 . 
         [0052]    At block  925 , a determination is made as to whether extensions exist. The determination at block  925  will be yes if the flag in field  300 - 10  contains a “yes”, and conversely the determination at block  925  will be no if the flag in field  300 - 10  contains a “no”. In the present example, field  300 - 10  contains “yes”, and therefore the determination at block  925  will be yes. At this point method  900  advances to block  930  and the interface is further generated to include linked appointment details. In the present example, the interface will therefore be further generated to include the data in fields  300 - 12  to field  300 - 17  as shown in  FIG. 8 . 
         [0053]      FIG. 10  shows an exemplary graphical interface  136 G-A that is generated as a result of performing method  900  according to the specific example discussed above. Note that the 1 p.m. to 2 p.m. entry, labeled  300 BASE, in interface  136 G-A includes the subject “Standards Meeting in Smithsville” and therefore corresponds to the data found in fields  300 - 1  to  300 - 9  of record  140 . Note that the 12 p.m. to 1 p.m. entry, labeled  300 LINK 1  includes the subject “Drive to Smithsville” and therefore corresponds to the data found in fields  300 - 12  through  300 - 14  of record  140 . Note that the 2 p.m. to 3 p.m. entry, labeled  300 LINK 2  includes the subject “Drive back from Smithsville” and therefore corresponds to the data found in fields  300 - 15  through  300 - 17  of record  140 . Graphical interface  136 G-A further includes a first link icon L 1  and a second link icon L 2 . Link icon L 1  represents the fact that the entry  300 LINK 1  is a first linked appointment that is linked to the entry  300 BASE. Link icon L 2  represents the fact that the entry  300 LINK 2  is a second linked appointment that is linked to the entry  300 BASE. 
         [0054]    Various advantages will now occur to those of skill in the art. One such advantage becomes apparent from the particular example shown in  FIGS. 11 and 12 . Indeed, method  500  can also be used to modify the contents of an existing record  140 .  FIG. 11  shows a graphical interface  140 G-B wherein the base appointments details are modified using method  500 . In  FIG. 11 , it can be specifically noted that the data in fields  300 - 4  through  300 - 6  have been modified. Specifically, the start time of the appointment (i.e. the contents of field  300 - 4 ) has been moved from 1 p.m. on Monday Mar. 26, 2007 to 1 p.m. on Tuesday, Mar. 27, 2007. Also in  FIG. 11  the duration of the appointment (i.e. the contents of field  300 - 6 ) has now been set to two hours. The end time of the appointment (i.e. the contents of field at  300 - 5 ) has correspondingly been modified. Once record  140  is saved in accordance with the modifications shown in  FIG. 11 , then a subsequent performance of method  900  leads to the generation of the graphical interface in  FIG. 12 . Advantageously, it can be noted that only the base appointments details needed to be modified. No modification of the linked appointment details was needed. 
         [0055]    Another advantage becomes apparent from the example shown in  FIG. 13 . In  FIG. 13 , server  58  is configured to maintain a copy of database  138  in the form of a synchronized database  138 S. Server  58  can be for example a Microsoft Exchange Server or a Blackberry Enterprise Server or the like. Database  138 S can be part of a personal information account that is respective to user U. The structure of record  140  permits the storage of data that can generate interface  136 G-A—yet without the structure of record  140 , three different records would be maintained. Therefore, using record  140 , volatile memory  116  or non-volatile memory  112  or both is used more efficiently, and bandwidth over link  70  or link  74  or both is used more efficiently. In a modified version of system  50 , where system  50  is a pure client-server model, and device  54  is simply a client machine that does not persistently maintain record  140  but instead relies on accessing record  140  via server  58  (e.g. via a web browser), then bandwidth over link  70  or link  74  or both is used more efficiently than would be achieved by transferring three different records that do not substantially conform with record the structure of  140 , (i.e. three records would be used instead: a first record for entry  300 LINK 1 , a second record for entry  300 BASE and a third record for entry  300 LINK 2 ) to generate interface  136 G-A. Similar bandwidth efficiency is gained during modification of record  140  as shown in  FIG. 11 , as bandwidth is only consumed for modification of record  140 , rather than three different records. 
         [0056]      FIG. 14  shows a flowchart depicting a method of data record management in accordance with another embodiment and indicated generally at  500 A. Method  500 A is a variation of method  500  and it can be noted that blocks  505 A,  510 A,  515 A and  530 A are the same as blocks  505 ,  510 ,  515  and  530 . Of note is that block  520 A is different from block  520 . In block  520 A, an identification of another appointment that is to be used for linking is received, instead of actually receiving the linked appointment details.  FIG. 15  shows a graphical interface  140 G-C that can be used to implement method  500 A. To implement block  520 A, interface  140 G-C includes field  300 - 17 . Field  300 - 17  comprises a drop down menu. The drop down menu lists a plurality of pre-existing appointment records that have been entered in different discrete records whereby the data for those records is entered into the corresponding fields  300 - 1  through  300 - 9 . By selecting one (or more) of those records listed in Field  300 - 17 , the contents of those other records are converted into the form shown in  FIG. 8 , and those corresponding records are then deleted. Those corresponding records are effectively converted into linked appointments, all having been merged and thereafter maintained within a single data record  140  rather than in multiple separate calendar records. 
         [0057]    Variations, combinations or subsets or all of the foregoing of the embodiments are contemplated. For example, it should be understood that the nature of the appointments to be linked is not limited to travel times as shown in the specific examples herein. It can be desired, for example, to link other types of appointments. For example, where a base appointment is a lunch meeting, a linked calendar appointment could be an appointment to remind the user to order lunch for the lunch meeting. As another example, it should be understood that the base calendar appointment can span a number of days or can be a recurring appointment or both, and therefore the linked appointments can likewise span a number of days or can be recurring or both. Where the base appointment details span a number of days such that the linked appointment details may be hidden, then link icons, like link icons L 1  or L 2 , can appear over the base appointment details, and can be active so that, upon selection of those icons, the linked appointment details can be dynamically generated but otherwise remain hidden.