DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
Acknowledgment is made of the information disclosure statements filed on November 14th, 2023 and December 2nd 2024. The U.S. patents and Foreign Patents have been considered.
Drawings
The drawings submitted on June 30, 2023 have been considered and accepted.
Claim Objections
Claim 5 is objected to because of the following informality:
In claim 5 line 4, “… has been has been deleted on the server” should read “…
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 10, 12-14 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Frank et al. (Pub. No. US 2016/0203444), hereinafter Frank; in view of Chang (Pub. No. US 2017/0083871), hereinafter Chang.
Claim 1. Frank discloses A computer-implemented method performed by a server, for generating secure calendar data for a user device, the method comprising:
generating a first calendar object associated with a first date and comprising a first secure token (See Parag. [0006]; a controller configured to generate a calendar object configured to store unique calendar user identifiers identifying users associated with the calendar object and one or more event objects, each of the one or more event objects comprising an authorization value. The controller may be further configured to generate a calendar share identifier associated with the calendar object. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information. See Parag. [0028]; shared calendar to be carefully managed in order to at least partially prevent undesired overexposure of one or more portions or aspects of the calendar. For example, one or more portions or aspects of a calendar may comprise confidential and/or sensitive information that the scheduler or manager of the calendar may not wish to share beyond a subset of shared users of the calendar. See also Parag. [0088]);
storing the first calendar object on the server (See Parag. [0006]; store the calendar object in the non-volatile data storage medium. See Parag. [0036]; The host server 220 may contain a calendar/user data repository 222);
providing the first calendar object to the user device (See Parag. [0006]; cause the calendar share identifier to be provided to each of a plurality of calendar users);
storing on the server a plurality of further calendar objects for communication to the user device, each of the further calendar objects being associated with a respective date and comprising content data defining an entry in the calendar (See Parag. [0032]; the host server(s) 120 may contain a repository of calendar and/or user data 122 as well as a calendar application server 124. The calendar and/or user data repository, or data store, 122. See Parag. [0038]; the calendar data store 222 may maintain various types of calendar and/or user-related data. For example, the data stored in the data store may include client account data 223a. See Parag. [0040]; Examples of user data 222 may include device configuration preferences stored on the host server for client device synchronization and/or backup/retrieval, contact lists, or default greetings for calendar users. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information);
receiving a request for calendar synchronisation from the user device (See Parag. [0050]; The synchronization module 225c may support synchronization of calendar data 223b between the server(s) and device(s), as well as between local device calendar data and the device's native calendar data 323k … allow for a user/device to query the application server 224 to determine a calendar state and determine if a refresh of calendar data is required. See also Parag. [0092]);
generating a second calendar object associated with a second date and comprising a second secure token (See Parag. [0093]; An update to calendar data may contain calendar data for a new calendar (e.g., calendar object));
storing the second calendar object on the server (See Parag. [0093]; the calendar data may be updated in the system calendar data store 604);
notifying the user device of a respective version of the first calendar object, the second calendar object, and each of the plurality of further calendar objects stored on the server, wherein the user device is notified that the first calendar object on the server has a version older than the first calendar object provided to the user device (See Parag. [0094-0095]; After the system calendar data store is updated, the calendar system may generate synchronization data (block 606) to be distributed to client devices. For example, synchronization data may comprise a set of notifications to push to users via a sockets service list and/or associated targets for calendar ID. The notification on the client device may trigger a pull of the calendar data. Synchronization data may include, but would not be limited to, notification messages, calendar change history, summarized calendar data, and/or other data … After synchronization data has been created, the system may provide calendar data updates to a client device as identified by the Share ID in process step 608. See also Fig. 8);
receiving from the user device the first calendar object and any calendar object stored on the user device having a version that is newer on the user device than the version notified by the server (See Parag. [0096-0098]; a process for the use of a Share ID by a calendar user associate one or more calendars to a client device … After update of the data store with a new Share ID, a device's calendar system may request calendar updates from a host server and/or other server/service, as shown in block 706; the request for calendar updates may be initiated by a calendar user. The request for calendar updates may include one or more Share ID(s));
upon successful authentication of the request, providing to the user device the second calendar object comprising the second secure token and any calendar object of the plurality of further calendar objects stored on the server having a version that is newer on the server than on the user device (See Parag. [0070-0071]; when an authenticated client device receives or has a unique calendar ID added to the user/devices calendar list, a single notification message may be sent to the user/device and all relevant calendar data may be available to the client device to refresh the local calendar data. The device security module 325b may contains processes and data required to support user device authentication and security management. Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods. See also Parag. [0039]; The access management module 225a may be configured to interface with one or more other modules of the application server 224, such as a synchronization module 225c and/or calendar integration module 225d, to determine changes/updates to data stored in the calendar data store 222 as well as to communicate the data to client devices 110, such as via the synchronization module 225c. The access management module 225a may implement one or more forms of authentication of user clients using native device identification); and
upon unsuccessful authentication of the request, restricting the user device from accessing the content data in the further calendar objects (See Parag. [0071]; Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods. See Parag. [0039]; the access management module 225a may implement one or more forms of authentication of user clients using native device identification (e.g. phone # and text) or through external authentication sources (e.g. third-party social media sites)).
Frank doesn’t explicitly disclose authenticating the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server.
However, Chang discloses authenticating the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server (See Parag. [0054]; Content management system 100 can also include authenticator module 306, which verifies user credentials, security tokens, API calls, specific client devices, etc., to determine whether access to requested content items is authorized, and is one means for performing this function. Authenticator module 306 can generate one-time use authentication tokens for a user account. Authenticator module 306 assigns an expiration period or date to each authentication token. In addition to sending the authentication tokens to requesting client devices, authenticator module 306 can store generated authentication tokens in authentication token database 320. After receiving a request to validate an authentication token, authenticator module 306 checks authentication token database 320 for a matching authentication token assigned to the user. Once authenticator module 306 identifies a matching authentication token, authenticator module 306 determines if the matching authentication token is still valid. For example, authenticator module 306 verifies that the authentication token has not expired or was not marked as used or invalid. After validating an authentication token, authenticator module 306 may invalidate the matching authentication token, such as a single-use token. For example, authenticator module 306 can mark the matching authentication token as used or invalid, or delete the matching authentication token from authentication token database 320).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank, to include authenticating the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server, as taught by Chang. This would be convenient to verify user credentials, security tokens, API calls, specific client devices, to determine whether access to requested content items is authorized (Chang, Parag. [0054]).
Claim 2. Frank in view of Chang discloses the method of Claim 1, further comprising:
Frank further discloses setting the version of the first calendar object on the server to be older than the version of the first calendar object provided to the user device, and wherein the older version of the first calendar object is stored on the server prior to receiving the request for calendar synchronisation from the user device (See Parag. [0088] and Fig. 5 (“502”); a calendar scheduler/user may have created and saved a calendar in a local and/or remote data store 502. See Parag. [0094]; After the system calendar data store is updated, the calendar system may generate synchronization data (block 606) to be distributed to client devices); and
setting the version of the second calendar object on the server to be older than the version of the second calendar object provided to the user device, and wherein the older version of the second calendar object is stored on the server prior to receiving a second request for calendar synchronisation from the user device (See Parag. [0092-0093]; a host server may receive a request to update calendar data. In certain embodiments, the request may indicate a data trigger identifying the need to update other user/device calendars. A request may come from a calendar user (e.g., calendar user 114) … An update to calendar data may contain calendar data for a new calendar (e.g., calendar object), and/or updates to a current calendar, as specified. After receipt and/or possible conversion of calendar data formats, the calendar data may be updated in the system calendar data store 604 … ).
Claim 3. Frank in view of Chang discloses the method of Claim 1, further comprising, when the authentication of the request is successful:
Frank further discloses receiving a further request for calendar synchronisation from the user device; and notifying the user device that the first calendar object stored on the server has been deleted (See Parag. [0092-0094]; a host server may receive a request to update calendar data. The request may indicate a data trigger identifying the need to update other user/device calendars. A request may come from a calendar user (e.g., calendar user 114) … After the system calendar data store is updated, the calendar system may generate synchronisation data (block 606) to be distributed to client devices; synchronization data may comprise a set of notifications to push to users via a sockets service list and/or associated targets for calendar ID. The notification on the client device may trigger a pull of the calendar data. Synchronization data may include, but would not be limited to, notification messages, calendar change history, summarized calendar data, and/or other data. In certain embodiments, this data may be substantially immediately processed by the system, such as where the client devices are actively connected to the calendar system and an immediate push of calendar data updates is desired or possible, such as through the use of sockets and a target list of active users/devices. See Parag. [0027]; it may be necessary for the recipient to forward the original event in addition to any subsequent updates to the secondary recipient in order to ensure that the up-to-date event information is communicated to the secondary recipient).
Claim 4. Frank in view of Chang discloses the method of Claims 1, further comprising:
Frank further discloses receiving further requests for calendar synchronisation from the user device, wherein, for each new request for calendar synchronisation from the user device, the server generates a new calendar object comprising a new secure token and, if the new request is authenticated, the new calendar object is provided to the user device (See Parag. [0070-0071]; when an authenticated client device receives or has a unique calendar ID added to the user/devices calendar list, a single notification message may be sent to the user/device and all relevant calendar data may be available to the client device to refresh the local calendar data. The device security module 325b may contains processes and data required to support user device authentication and security management. Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods. See also Parag. [0039]; The access management module 225a may be configured to interface with one or more other modules of the application server 224, such as a synchronization module 225c and/or calendar integration module 225d, to determine changes/updates to data stored in the calendar data store 222 as well as to communicate the data to client devices 110, such as via the synchronization module 225c. The access management module 225a may implement one or more forms of authentication of user clients using native device identification).
Claim 5. Frank in view of Chang discloses the method of Claim 4, further comprising:
Frank further discloses in response to each of the further requests for calendar synchronisation, notifying the user device that a previous calendar object comprising a secure token previously provided to the user device has been has been deleted on the server (See Parag. [0092-0094]; a host server may receive a request to update calendar data. In certain embodiments, the request may indicate a data trigger identifying the need to update other user/device calendars. A request may come from a calendar user (e.g., calendar user 114) … After the system calendar data store is updated, the calendar system may generate synchronisation data (block 606) to be distributed to client devices; synchronization data may comprise a set of notifications to push to users via a sockets service list and/or associated targets for calendar ID. The notification on the client device may trigger a pull of the calendar data. Synchronization data may include, but would not be limited to, notification messages, calendar change history, summarized calendar data, and/or other data. In certain embodiments, this data may be substantially immediately processed by the system, such as where the client devices are actively connected to the calendar system and an immediate push of calendar data updates is desired or possible, such as through the use of sockets and a target list of active users/devices. See Parag. [0027]; it may be necessary for the recipient to forward the original event in addition to any subsequent updates to the secondary recipient in order to ensure that the up-to-date event information is communicated to the secondary recipient).
Claim 10. Frank in view of Chang discloses the method of Claims 1,
Frank further discloses wherein each of the first date and the second date is generated randomly by the server (See Parag. [0006]; a controller configured to generate a calendar object configured to store unique calendar user identifiers identifying users associated with the calendar object and one or more event objects, each of the one or more event objects comprising an authorization value. The controller may be further configured to generate a calendar share identifier associated with the calendar object. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information).
Claim 12. Frank in view of Chang discloses the method of Claims 1,
Chang further discloses wherein the first secure token comprises data indicating an expiry time for the first secure token, and wherein the authentication of the request is determined to be unsuccessful if the request is received after the expiry time has passed (See Parag. [0054]; After receiving a request to validate an authentication token, authenticator module 306 checks authentication token database 320 for a matching authentication token assigned to the user. Once authenticator module 306 identifies a matching authentication token, authenticator module 306 determines if the matching authentication token is still valid. For example, authenticator module 306 verifies that the authentication token has not expired or was not marked as used or invalid. After validating an authentication token, authenticator module 306 may invalidate the matching authentication token, such as a single-use token. For example, authenticator module 306 can mark the matching authentication token as used or invalid, or delete the matching authentication token from authentication token database 320).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank, to include wherein the first secure token comprises data indicating an expiry time for the first secure token, and wherein the authentication of the request is determined to be unsuccessful if the request is received after the expiry time has passed, as taught by Chang. This would be convenient to verify user credentials, security tokens, API calls, specific client devices, to determine whether access to requested content items is authorized (Chang, Parag. [0054]).
Claim 13. Frank in view of Chang discloses the method of Claims 1,
Chang further discloses wherein the authentication of the request is determined to be unsuccessful if a time elapsed between the provision of the first calendar object to the user device and the reception of the request by the server is greater than a predetermined validity period for the first secure token (See Parag. [0054]; After receiving a request to validate an authentication token, authenticator module 306 checks authentication token database 320 for a matching authentication token assigned to the user. Once authenticator module 306 identifies a matching authentication token, authenticator module 306 determines if the matching authentication token is still valid. For example, authenticator module 306 verifies that the authentication token has not expired or was not marked as used or invalid. After validating an authentication token, authenticator module 306 may invalidate the matching authentication token, such as a single-use token. For example, authenticator module 306 can mark the matching authentication token as used or invalid, or delete the matching authentication token from authentication token database 320).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank, to include wherein the authentication of the request is determined to be unsuccessful if a time elapsed between the provision of the first calendar object to the user device and the reception of the request by the server is greater than a predetermined validity period for the first secure token, as taught by Chang. This would be convenient to verify user credentials, security tokens, API calls, specific client devices, to determine whether access to requested content items is authorized (Chang, Parag. [0054]).
Claim 14. Frank in view of Chang discloses the method of Claim 1,
Frank further discloses wherein, upon unsuccessful authentication, the server restricts the user device from accessing the content data in the further calendar objects by not providing to the user device any of the plurality of further calendar objects stored on the server (See Parag. [0071]; Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods).
Claim 21. Frank discloses a server comprising at least one processor and at least one memory storing computer-readable instructions (See Parag. [0006] [0036]; Host server), which, when executed by the at least one processor, cause the at least one processor:
generate a first calendar object associated with a first date and comprising a first secure token (See Parag. [0006]; a controller configured to generate a calendar object configured to store unique calendar user identifiers identifying users associated with the calendar object and one or more event objects, each of the one or more event objects comprising an authorization value. The controller may be further configured to generate a calendar share identifier associated with the calendar object. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information. See Parag. [0028]; shared calendar to be carefully managed in order to at least partially prevent undesired overexposure of one or more portions or aspects of the calendar. For example, one or more portions or aspects of a calendar may comprise confidential and/or sensitive information that the scheduler or manager of the calendar may not wish to share beyond a subset of shared users of the calendar. See also Parag. [0088]);
store the first calendar object on the server (See Parag. [0006]; store the calendar object in the non-volatile data storage medium. See Parag. [0036]; The host server 220 may contain a calendar/user data repository 222);
provide the first calendar object to the user device (See Parag. [0006]; cause the calendar share identifier to be provided to each of a plurality of calendar users);
store on the server a plurality of further calendar objects for communication to the user device, each of the further calendar objects being associated with a respective date and comprising content data defining an entry in the calendar (See Parag. [0032]; the host server(s) 120 may contain a repository of calendar and/or user data 122 as well as a calendar application server 124. The calendar and/or user data repository, or data store, 122. See Parag. [0038]; the calendar data store 222 may maintain various types of calendar and/or user-related data. For example, the data stored in the data store may include client account data 223a. See Parag. [0040]; Examples of user data 222 may include device configuration preferences stored on the host server for client device synchronization and/or backup/retrieval, contact lists, or default greetings for calendar users. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information);
receive a request for calendar synchronisation from the user device (See Parag. [0050]; The synchronization module 225c may support synchronization of calendar data 223b between the server(s) and device(s), as well as between local device calendar data and the device's native calendar data 323k … allow for a user/device to query the application server 224 to determine a calendar state and determine if a refresh of calendar data is required. See also Parag. [0092]);
generate a second calendar object associated with a second date and comprising a second secure token (See Parag. [0093]; An update to calendar data may contain calendar data for a new calendar (e.g., calendar object));
store the second calendar object on the server (See Parag. [0093]; the calendar data may be updated in the system calendar data store 604);
notify the user device of a respective version of the first calendar object, the second calendar object, and each of the plurality of further calendar objects stored on the server, wherein the user device is notified that the first calendar object on the server has a version older than the first calendar object provided to the user device (See Parag. [0094-0095]; After the system calendar data store is updated, the calendar system may generate synchronization data (block 606) to be distributed to client devices. For example, synchronization data may comprise a set of notifications to push to users via a sockets service list and/or associated targets for calendar ID. The notification on the client device may trigger a pull of the calendar data. Synchronization data may include, but would not be limited to, notification messages, calendar change history, summarized calendar data, and/or other data … After synchronization data has been created, the system may provide calendar data updates to a client device as identified by the Share ID in process step 608. See also Fig. 8);
receive from the user device the first calendar object and any calendar object stored on the user device having a version that is newer on the user device than the version notified by the server (See Parag. [0096-0098]; a process for the use of a Share ID by a calendar user associate one or more calendars to a client device … After update of the data store with a new Share ID, a device's calendar system may request calendar updates from a host server and/or other server/service, as shown in block 706; the request for calendar updates may be initiated by a calendar user. The request for calendar updates may include one or more Share ID(s));
upon successful authentication of the request, provide to the user device the second calendar object comprising the second secure token and any calendar object of the plurality of further calendar objects stored on the server having a version that is newer on the server than on the user device (See Parag. [0070-0071]; when an authenticated client device receives or has a unique calendar ID added to the user/devices calendar list, a single notification message may be sent to the user/device and all relevant calendar data may be available to the client device to refresh the local calendar data. The device security module 325b may contains processes and data required to support user device authentication and security management. Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods. See also Parag. [0039]; The access management module 225a may be configured to interface with one or more other modules of the application server 224, such as a synchronization module 225c and/or calendar integration module 225d, to determine changes/updates to data stored in the calendar data store 222 as well as to communicate the data to client devices 110, such as via the synchronization module 225c. The access management module 225a may implement one or more forms of authentication of user clients using native device identification); and
upon unsuccessful authentication of the request, restrict the user device from accessing the content data in the further calendar objects (See Parag. [0071]; Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods).
Frank doesn’t explicitly disclose authenticate the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server.
However, Chang discloses authenticate the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server (See Parag. [0054] Content management system 100 can also include authenticator module 306, which verifies user credentials, security tokens, API calls, specific client devices, etc., to determine whether access to requested content items is authorized, and is one means for performing this function. Authenticator module 306 can generate one-time use authentication tokens for a user account. Authenticator module 306 assigns an expiration period or date to each authentication token. In addition to sending the authentication tokens to requesting client devices, authenticator module 306 can store generated authentication tokens in authentication token database 320. After receiving a request to validate an authentication token, authenticator module 306 checks authentication token database 320 for a matching authentication token assigned to the user. Once authenticator module 306 identifies a matching authentication token, authenticator module 306 determines if the matching authentication token is still valid. For example, authenticator module 306 verifies that the authentication token has not expired or was not marked as used or invalid. After validating an authentication token, authenticator module 306 may invalidate the matching authentication token, such as a single-use token. For example, authenticator module 306 can mark the matching authentication token as used or invalid, or delete the matching authentication token from authentication token database 320).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank, to include authenticating the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server, as taught by Chang. This would be convenient to verify user credentials, security tokens, API calls, specific client devices, to determine whether access to requested content items is authorized (Chang, Parag. [0054]).
Claim 22. Frank discloses a non-transitory computer-readable storage medium storing computer program instructions, which, when executed by at least one processor (See Parag. [0125-0127]), cause the at least one processor to:
generate a first calendar object associated with a first date and comprising a first secure token (See Parag. [0006]; a controller configured to generate a calendar object configured to store unique calendar user identifiers identifying users associated with the calendar object and one or more event objects, each of the one or more event objects comprising an authorization value. The controller may be further configured to generate a calendar share identifier associated with the calendar object. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information. See Parag. [0028]; shared calendar to be carefully managed in order to at least partially prevent undesired overexposure of one or more portions or aspects of the calendar. For example, one or more portions or aspects of a calendar may comprise confidential and/or sensitive information that the scheduler or manager of the calendar may not wish to share beyond a subset of shared users of the calendar. See also Parag. [0088]);
store the first calendar object on the server (See Parag. [0006]; store the calendar object in the non-volatile data storage medium. See Parag. [0036]; The host server 220 may contain a calendar/user data repository 222);
provide the first calendar object to the user device (See Parag. [0006]; cause the calendar share identifier to be provided to each of a plurality of calendar users);
store on the server a plurality of further calendar objects for communication to the user device, each of the further calendar objects being associated with a respective date and comprising content data defining an entry in the calendar (See Parag. [0032]; the host server(s) 120 may contain a repository of calendar and/or user data 122 as well as a calendar application server 124. The calendar and/or user data repository, or data store, 122. See Parag. [0038]; the calendar data store 222 may maintain various types of calendar and/or user-related data. For example, the data stored in the data store may include client account data 223a. See Parag. [0040]; Examples of user data 222 may include device configuration preferences stored on the host server for client device synchronization and/or backup/retrieval, contact lists, or default greetings for calendar users. See Parag. [0085]; Calendar events 430 may contain various parameters/attributes, such as date, time start, time end, organizer, invitees, and/or additional types of information);
receive a request for calendar synchronisation from the user device (See Parag. [0050]; The synchronization module 225c may support synchronization of calendar data 223b between the server(s) and device(s), as well as between local device calendar data and the device's native calendar data 323k … allow for a user/device to query the application server 224 to determine a calendar state and determine if a refresh of calendar data is required. See also Parag. [0092]);
generate a second calendar object associated with a second date and comprising a second secure token (See Parag. [0093]; An update to calendar data may contain calendar data for a new calendar (e.g., calendar object));
store the second calendar object on the server (See Parag. [0093]; the calendar data may be updated in the system calendar data store 604);
notify the user device of a respective version of the first calendar object, the second calendar object, and each of the plurality of further calendar objects stored on the server, wherein the user device is notified that the first calendar object on the server has a version older than the first calendar object provided to the user device (See Parag. [0094-0095]; After the system calendar data store is updated, the calendar system may generate synchronization data (block 606) to be distributed to client devices. For example, synchronization data may comprise a set of notifications to push to users via a sockets service list and/or associated targets for calendar ID. The notification on the client device may trigger a pull of the calendar data. Synchronization data may include, but would not be limited to, notification messages, calendar change history, summarized calendar data, and/or other data … After synchronization data has been created, the system may provide calendar data updates to a client device as identified by the Share ID in process step 608. See also Fig. 8);
receive from the user device the first calendar object and any calendar object stored on the user device having a version that is newer on the user device than the version notified by the server (See Parag. [0096-0098]; a process for the use of a Share ID by a calendar user associate one or more calendars to a client device … After update of the data store with a new Share ID, a device's calendar system may request calendar updates from a host server and/or other server/service, as shown in block 706; the request for calendar updates may be initiated by a calendar user. The request for calendar updates may include one or more Share ID(s));
upon successful authentication of the request, provide to the user device the second calendar object comprising the second secure token and any calendar object of the plurality of further calendar objects stored on the server having a version that is newer on the server than on the user device (See Parag. [0070-0071]; when an authenticated client device receives or has a unique calendar ID added to the user/devices calendar list, a single notification message may be sent to the user/device and all relevant calendar data may be available to the client device to refresh the local calendar data. The device security module 325b may contains processes and data required to support user device authentication and security management. Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods. See also Parag. [0039]; The access management module 225a may be configured to interface with one or more other modules of the application server 224, such as a synchronization module 225c and/or calendar integration module 225d, to determine changes/updates to data stored in the calendar data store 222 as well as to communicate the data to client devices 110, such as via the synchronization module 225c. The access management module 225a may implement one or more forms of authentication of user clients using native device identification); and
upon unsuccessful authentication of the request, restrict the user device from accessing the content data in the further calendar objects (See Parag. [0071]; Calendar information 323b on the device may be stored in a secured manner and available only to authorized users and/or by authorized methods).
Frank doesn’t explicitly disclose authenticate the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server.
However, Chang discloses authenticate the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server (See Parag. [0054] Content management system 100 can also include authenticator module 306, which verifies user credentials, security tokens, API calls, specific client devices, etc., to determine whether access to requested content items is authorized, and is one means for performing this function. Authenticator module 306 can generate one-time use authentication tokens for a user account. Authenticator module 306 assigns an expiration period or date to each authentication token. In addition to sending the authentication tokens to requesting client devices, authenticator module 306 can store generated authentication tokens in authentication token database 320. After receiving a request to validate an authentication token, authenticator module 306 checks authentication token database 320 for a matching authentication token assigned to the user. Once authenticator module 306 identifies a matching authentication token, authenticator module 306 determines if the matching authentication token is still valid. For example, authenticator module 306 verifies that the authentication token has not expired or was not marked as used or invalid. After validating an authentication token, authenticator module 306 may invalidate the matching authentication token, such as a single-use token. For example, authenticator module 306 can mark the matching authentication token as used or invalid, or delete the matching authentication token from authentication token database 320).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank, to include authenticating the request by comparing the first secure token from the first calendar object received from the user device and the first secure token from the first calendar object stored on the server, as taught by Chang. This would be convenient to verify user credentials, security tokens, API calls, specific client devices, to determine whether access to requested content items is authorized (Chang, Parag. [0054]).
Claims 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Frank et al. (Pub. No. US 2016/0203444), hereinafter Frank; in view of Chang (Pub. No. US 2017/0083871), hereinafter Chang; in further view of Grajeck et. al. (Pub. No. US 2015/0237038), hereinafter Grajeck.
Claim 6. Frank in view of Chang discloses the method of Claim 1, further comprising:
Frank further discloses determining a first value of at least one parameter that is at least partially characteristic of the user device prior to receiving the request for calendar synchronisation, the first value of each parameter being determined from a registration of the user device with the server and/or from an earlier request for calendar synchronisation from the user device; and determining a second value of each parameter from the request for calendar synchronisation; (See Parag. [0039]; the access management module 225a may be configured to interface with one or more other modules of the application server 224, such as a synchronization module 225c and/or calendar integration module 225d, to determine changes/updates to data stored in the calendar data store 222 as well as to communicate the data to client devices 110, such as via the synchronization module 225c. The access management module 225a may implement one or more forms of authentication of user clients using native device identification).
Frank in view of Chang doesn’t explicitly disclose wherein authenticating the request further comprises: determining a validation score based on a comparison of each first value and the corresponding second value; determining the authentication of the request to be unsuccessful if the validation score is outside of a predetermined scoring range.
However, Grajeck discloses determining a validation score based on a comparison of each first value and the corresponding second value; determining the authentication of the request to be unsuccessful if the validation score is outside of a predetermined scoring range (See Parag. [0007]; a computerized fingerprint-based authentication system comprises: one or more hardware processors configured to cause the fingerprint-based authentication system to: receive, over a network, a request for authentication of a user computing device associated with a user, the request resulting from a redirection operation sent to the user computing device from a network service requiring additional authentication in addition to a password; send, over the network, to the user computing device, capture instructions, the capture instructions configured to cause the user computing device to collect a first plurality of characteristic values of the user computing device, the first plurality of the characteristic values representing at least two attributes of the user computing device; receive, over the network, the first plurality of characteristic values of the user computing device; compare the first plurality of characteristic values of the user computing device to a second plurality of characteristic values, the second plurality of characteristic values previously stored by the computerized fingerprint-based authentication system; determine a device certainty score based on a comparison of the first plurality of characteristic values of the user computing device to the second plurality of characteristic values; and when a determination is made that the device certainty score is above a threshold update score: update the second plurality of characteristic values in data storage to include the first plurality of characteristic values, and transmit an authentication token to the user computing device, the authentication token indicating that the user computing device was authenticated by a fingerprinting mechanism).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank in view of Chang, to include determining a validation score based on a comparison of each first value and the corresponding second value; determining the authentication of the request to be unsuccessful if the validation score is outside of a predetermined scoring range, as taught by Grajeck. This would be convenient to authenticate users and their devices based on device fingerprinting (Grajeck, Parag. [0002]).
Claim 7. Frank in view of Chang and Grajeck discloses the method of Claim 6,
Chang further discloses wherein the first secure token comprises encrypted data based on each first value, and the validation score is determined based on a comparison of each first value determined from the data of the first secure token from the first calendar object stored on the server and the corresponding second value determined from the synchronisation request (See Parag. [0039]; client devices 120 communicate with content management system 100 through network 110. The network may be any suitable communications network for data transmission… all or some of links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc. See Parag. [0054]; Content management system 100 can also include authenticator module 306, which verifies user credentials, security tokens, API calls, specific client devices, etc., to determine whether access to requested content items is authorized, and is one means for performing this function. Authenticator module 306 can generate one-time use authentication tokens for a user account. Authenticator module 306 assigns an expiration period or date to each authentication token. In addition to sending the authentication tokens to requesting client devices, authenticator module 306 can store generated authentication tokens in authentication token database 320. After receiving a request to validate an authentication token, authenticator module 306 checks authentication token database 320 for a matching authentication token assigned to the user. Once authenticator module 306 identifies a matching authentication token, authenticator module 306 determines if the matching authentication token is still valid. For example, authenticator module 306 verifies that the authentication token has not expired or was not marked as used or invalid. After validating an authentication token, authenticator module 306 may invalidate the matching authentication token, such as a single-use token. For example, authenticator module 306 can mark the matching authentication token as used or invalid, or delete the matching authentication token from authentication token database 320).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Frank, to include the first secure token comprises encrypted data based on each first value, and the validation score is determined based on a comparison of each first value determined from the data of the first secure token from the first calendar object stor