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 .
DETAILED ACTION
Response to Amendment
This is a reply to the request for Continued Examination (RCE) filed on 2/25/2026, in which Claim(s) 1-16 are presented for examination.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/25/2026 has been entered.
Response to Argument
Claim Rejections - 35 U.S.C. § 102 and 35 U.S.C. § 103:
Applicant’s arguments with respect to the rejection of claim(s) 1-16 have been considered but are moot in view of the new ground(s) of rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 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.
Claim(s) 1-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Holyfield et al. (US 20150271146 A1; hereinafter Holyfield) in view of Chester et al. (US 20210004454 A1; hereinafter Chester) further in view of Madhavan et al. (US 20220198053 A1; hereinafter Madhavan).
Regarding claims 1, 12 and 13, Holyfield discloses a computer implemented method for securely sharing underlying data of a data owner to a data recipient [Holyfield; Figs. 1, 3 and associated texts], said method comprising:
providing access to the underlying data of the data owner to a data server of a sharing intermediary (a sender transmits, via user device, encrypted data to the DS/Server [Holyfield; ¶22, 26-28; Figs. 1, 3 and associated texts]);
obtaining personalised data confidence information from a data communication of the data owner and providing said personalised data confidence information to the sharing intermediary (the sender can add encrypted data to the package, the sender sends the client secret which may be combined with the server secret to the DS/Server [Holyfield; ¶26-28; Figs. 1, 3 and associated texts]);
storing said underlying data and said personalised data confidence information at the data server of the sharing intermediary, wherein the personalised data confidence information is associated with the underlying data (the encrypted package is stored at the DS/Server and the secret [Holyfield; ¶26-28; Figs. 1, 3 and associated texts]);
supplying a passphrase generated by the sharing intermediary to the data owner, said passphrase uniquely identifying associated with said underlying data (the DS/Server generate a unique package Id and server secrets and send it to the sender, the unique package id and server secret is used to identify the encrypted package [Holyfield; ¶24-27; Figs. 1, 3 and associated texts]);
supplying the passphrase and the data confidence information from the data owner to the data recipient (the sender sends the package Id and client secret to the recipient [Holyfield; ¶27, 31-33; Figs. 1, 3 and associated texts]);
providing the passphrase and the data confidence information from the data terminal of the data recipient to the data server of sharing intermediary (the recipient sends the package Id with the authentication code to the DS/Server [Holyfield; ¶27-36; Figs. 1, 3 and associated texts]);
checking, by the data server of the sharing intermediary, whether the passphrase provided by the data recipient matches a stored passphrase associated with the stored underlying data (The DS/server looks up the package associated with the specified package identifier and, if found, the server retrieves the list of recipients associated with the package [Holyfield; ¶34-36; Figs. 1, 3 and associated texts]); and
supplying the underlying data from the data server of the sharing intermediary to the data terminal of the data recipient if the passphrase provided by the terminal of the data recipient matches the passphrase associated with the underlying data stored at the data server of the sharing intermediary (if the specific package identifier found/match, the server sends the encrypted package to the recipient [Holyfield; ¶34-36; Figs. 1, 3 and associated texts]). Holyfield discloses the recipient sending of the package Id and the authentication code to be validated by the server for validation and obtaining the encrypted package. Furthermore, the claim does not specify what is a passphrase; however, to advance prosecution. The Examiner points toward Chester.
In particular, Chester teaches the user devices of the server may generated the shared secrets, such any shared credentials elements may be a suitable shared secrets such as password, passphrase, keys, etc., [Chester; ¶40-43]. It would have been obvious before the effective filing date of the claimed invention to modify Holyfield in view of Chester shared secrets flexibility with the motivation for flexible authentication and reduces the number of communications such as sending extra emails/SMS.
Holyfield-Chester combination discloses sending of passcode and share secret to validating the user and allow access to data. Holyfield-Chester combination does not explicilty discloses supplying, by the data server of the sharing intermediary, said personalised data confidence information to the data terminal of the data recipient; and determining, by the data recipient, whether the personalised data confidence information provided by the data server of the sharing intermediary matches the personalised data confidence information of the data owner; however, in a related and analogous art, Madhavan teaches these features.
Madhavan teaches multifactor authentication, upon request, first authenticate with passcode and followed by another form of authentication, such as PIN or answer to personal questions. If the user is authenticated, they can accept and view the contents [Madhavan; ¶240-245; figs 23-24 and associated texts]. It would have been obvious before the effective filing date of the claimed invention to modify Holyfield-Chester combination in view of Madhavan MFA using personal questions with the motivation allowing multiple ways of authentication and not just secure secret and temp code.
With respect to application’s remarks such that the personalized data confidence is related to the data owner such as their heights and hair colors, etc.; however, based on the claim, the BRI for personalized data confidence information can be of anything, such as PIN or challenge questions such as your dog’s name, etc… As such, the MFA with challenge question would read on the current claim limitation.
Regarding claim 2, Holyfield-Chester-Madhavan combination discloses the method of claim 1, wherein the step of providing access to the underlying data of the data owner to a sharing intermediary further comprises the step of providing data filters, said data filters filtering said underlying data of the data owner provided to the sharing intermediary (A registered user may be defined as one who has enrolled in the system as a customer. Authentication for registered users may occur by various methods, including but not limited to OpenId, OAuth or directly using the system-managed login mechanism (with, for example, a username and password). Registered users may also be associated with a corporate entity or may be stand-alone (individual) users and have full access to all system features and capabilities and limited only by the usage tier assigned to them. An un-registered user may be someone who has received a package from a registered user or who has had a request for files sent to him/her by a registered user, such as the UR sender. Un-registered user access may be limited to exchanging data with the registered user(s) who initiate the data exchange. Un-registered users may additionally be restricted from making requests for files from other users [Holyfield; ¶71-73, 79; Figs. 1-3 and associated texts]).
Regarding claim 3, Holyfield-Chester-Madhavan combination discloses the method of claim 2, further comprising the step of providing a preview of the filtered underlying data to the data owner prior to providing said filtered underlying data to the sharing intermediary (A registered user may be defined as one who has enrolled in the system as a customer. Authentication for registered users may occur by various methods, including but not limited to OpenId, OAuth or directly using the system-managed login mechanism (with, for example, a username and password). Registered users may also be associated with a corporate entity or may be stand-alone (individual) users and have full access to all system features and capabilities and limited only by the usage tier assigned to them. An un-registered user may be someone who has received a package from a registered user or who has had a request for files sent to him/her by a registered user, such as the UR sender. Un-registered user access may be limited to exchanging data with the registered user(s) who initiate the data exchange. Un-registered users may additionally be restricted from making requests for files from other users [Holyfield; ¶71-73, 79; Figs. 1-3 and associated texts]).
Regarding claim 4, Holyfield-Chester-Madhavan combination discloses the method of claim 1, wherein the step of providing access to the underlying data of the data owner further comprises the step of anonymising the underlying data prior to providing access to the sharing intermediary (A registered user may be defined as one who has enrolled in the system as a customer. Authentication for registered users may occur by various methods, including but not limited to OpenId, OAuth or directly using the system-managed login mechanism (with, for example, a username and password). Registered users may also be associated with a corporate entity or may be stand-alone (individual) users and have full access to all system features and capabilities and limited only by the usage tier assigned to them. An un-registered user may be someone who has received a package from a registered user or who has had a request for files sent to him/her by a registered user, such as the UR sender. Un-registered user access may be limited to exchanging data with the registered user(s) who initiate the data exchange. Un-registered users may additionally be restricted from making requests for files from other users [Holyfield; ¶71-73, 79; Figs. 1-3 and associated texts]).
Regarding claim 5, Holyfield-Chester-Madhavan combination discloses the method of claim1, wherein the step of providing access to the underlying data of the data owner further comprises the step of setting access limits on the underlying data (A registered user may be defined as one who has enrolled in the system as a customer. Authentication for registered users may occur by various methods, including but not limited to OpenId, OAuth or directly using the system-managed login mechanism (with, for example, a username and password). Registered users may also be associated with a corporate entity or may be stand-alone (individual) users and have full access to all system features and capabilities and limited only by the usage tier assigned to them. An un-registered user may be someone who has received a package from a registered user or who has had a request for files sent to him/her by a registered user, such as the UR sender (see e.g., FIG. 2, reference number 223). Un-registered user access may be limited to exchanging data with the registered user(s) who initiate the data exchange. Un-registered users may additionally be restricted from making requests for files from other users [Holyfield; ¶71-73, 79; Figs. 1-3 and associated texts]).
Regarding claim 6, Holyfield-Chester-Madhavan combination discloses the method of claim 1, further comprising the step of identifying the data recipient accessing the underlying data (One of ordinary skill will understand that there are a variety of mechanisms that could be used to identify recipients as long as each recipient is uniquely identified. In one embodiment of the invention, recipients are identified by their email address which is used to identify and authenticate (see also e.g., FIG. 3, reference numbers 312 and 313) the recipient before the server 115 permits access to the package. The specific method by which the recipient is authenticated is also not critical to the invention provided that they can be identified with relative confidence. For example, in one embodiment the user might be authenticated using as previously established user name and password combination, or might be authenticated by an authentication provider using a distributed authentication protocol like OpenId or OAuth. Additionally, the server 115 may wish to offer stronger levels of authentication, such as multi-factor authentication, if such means are available. In one embodiment, the server 115 could allow the sender to specify the mobile phone number of each recipient so that an authentication code can be sent to their mobile device to confirm their identity [Holyfield; ¶29; Figs. 1-3 and associated texts]).
Regarding claim 7, Holyfield-Chester-Madhavan combination discloses the method of claim 6, further comprising a step of logging identifier information of the data recipient against said underlying data after accessing said underlying data, to log the data access (One of ordinary skill will understand that there are a variety of mechanisms that could be used to identify recipients as long as each recipient is uniquely identified. In one embodiment of the invention, recipients are identified by their email address which is used to identify and authenticate (see also e.g., FIG. 3, reference numbers 312 and 313) the recipient before the server 115 permits access to the package. The specific method by which the recipient is authenticated is also not critical to the invention provided that they can be identified with relative confidence. For example, in one embodiment the user might be authenticated using as previously established user name and password combination, or might be authenticated by an authentication provider using a distributed authentication protocol like OpenId or OAuth. Additionally, the server 115 may wish to offer stronger levels of authentication, such as multi-factor authentication, if such means are available. In one embodiment, the server 115 could allow the sender to specify the mobile phone number of each recipient so that an authentication code can be sent to their mobile device to confirm their identity [Holyfield; ¶29; Figs. 1-3 and associated texts]).
Regarding claim 8, Holyfield-Chester-Madhavan combination discloses the method of claim 1, further comprising the step of supplying a local identifier of the data recipient for the underlying data to the sharing intermediary (One of ordinary skill will understand that there are a variety of mechanisms that could be used to identify recipients as long as each recipient is uniquely identified. In one embodiment of the invention, recipients are identified by their email address which is used to identify and authenticate (see also e.g., FIG. 3, reference numbers 312 and 313) the recipient before the server 115 permits access to the package. The specific method by which the recipient is authenticated is also not critical to the invention provided that they can be identified with relative confidence. For example, in one embodiment the user might be authenticated using as previously established user name and password combination, or might be authenticated by an authentication provider using a distributed authentication protocol like OpenId or OAuth. Additionally, the server 115 may wish to offer stronger levels of authentication, such as multi-factor authentication, if such means are available. In one embodiment, the server 115 could allow the sender to specify the mobile phone number of each recipient so that an authentication code can be sent to their mobile device to confirm their identity [Holyfield; ¶29; Figs. 1-3 and associated texts]).
Regarding claim 9, Holyfield-Chester-Madhavan combination discloses the method of claim 8, further comprising the step of tagging said underlying data with the data recipient's local identifier (One of ordinary skill will understand that there are a variety of mechanisms that could be used to identify recipients as long as each recipient is uniquely identified. In one embodiment of the invention, recipients are identified by their email address which is used to identify and authenticate (see also e.g., FIG. 3, reference numbers 312 and 313) the recipient before the server 115 permits access to the package. The specific method by which the recipient is authenticated is also not critical to the invention provided that they can be identified with relative confidence. For example, in one embodiment the user might be authenticated using as previously established user name and password combination, or might be authenticated by an authentication provider using a distributed authentication protocol like OpenId or OAuth. Additionally, the server 115 may wish to offer stronger levels of authentication, such as multi-factor authentication, if such means are available. In one embodiment, the server 115 could allow the sender to specify the mobile phone number of each recipient so that an authentication code can be sent to their mobile device to confirm their identity [Holyfield; ¶29; Figs. 1-3 and associated texts]).
Regarding claim 10, Holyfield-Chester-Madhavan combination discloses the method of claim1, wherein the step of providing access to the underlying data of the data owner to a sharing intermediary further comprises the step of receiving an additional data filter from the data recipient, such that only underlying data corresponding to the additional data filter is supplied to the data recipient (A registered user may be defined as one who has enrolled in the system as a customer. Authentication for registered users may occur by various methods, including but not limited to OpenId, OAuth or directly using the system-managed login mechanism (with, for example, a username and password). Registered users may also be associated with a corporate entity or may be stand-alone (individual) users and have full access to all system features and capabilities and limited only by the usage tier assigned to them. An un-registered user may be someone who has received a package from a registered user or who has had a request for files sent to him/her by a registered user, such as the UR sender (see e.g., FIG. 2, reference number 223). Un-registered user access may be limited to exchanging data with the registered user(s) who initiate the data exchange. Un-registered users may additionally be restricted from making requests for files from other users [Holyfield; ¶71-73, 79; Figs. 1-3 and associated texts]).
Regarding claim 11, Holyfield-Chester-Madhavan combination discloses the method of claim 1, wherein the sharing intermediary informs said data owner after the data recipient is supplied the underlying data (use a package object to represent a set of one or more related data elements that are being exchanged within the system. The package may include an owner (may be a reference to the user object associated with the package creator), one or more data objects, one or more recipients, and other attributes specific to the package. For example, the package may include an availability window that represents the number of days for which the data is retained within the system, and other attributes that can be used to determine the package status and the date/time of access by each recipient [Holyfield; ¶74; Figs. 1-3 and associated texts]).
Regarding claim 14, Holyfield-Chester-Madhavan combination discloses the method of claim 1, wherein the step of providing access to the underlying data of the data owner further comprises the step of stripping the underlying data of identifiers that identify the data owner (One of ordinary skill will understand that there are a variety of mechanisms that could be used to identify recipients as long as each recipient is uniquely identified. In one embodiment of the invention, recipients are identified by their email address which is used to identify and authenticate (see also e.g., FIG. 3, reference numbers 312 and 313) the recipient before the server 115 permits access to the package. The specific method by which the recipient is authenticated is also not critical to the invention provided that they can be identified with relative confidence. For example, in one embodiment the user might be authenticated using as previously established user name and password combination, or might be authenticated by an authentication provider using a distributed authentication protocol like OpenId or OAuth. Additionally, the server 115 may wish to offer stronger levels of authentication, such as multi-factor authentication, if such means are available. In one embodiment, the server 115 could allow the sender to specify the mobile phone number of each recipient so that an authentication code can be sent to their mobile device to confirm their identity [Holyfield; ¶29; Figs. 1-3 and associated texts]).
Regarding claim 15, Holyfield-Chester-Madhavan combination discloses the method of claim 14, wherein the step of stripping the underlying data of identifiers comprises the step of selecting one or more fields within the underlying data that comprise no metadata identifiers that identify the data owner (only information regarding the files and not the owner [Holyfield; ¶75; Figs. 1-3 and associated texts]).
Regarding claim 16, Holyfield-Chester-Madhavan combination discloses the method of claim 1, whereby if the data confidence information does not match the personalised data confidence information associated with the underlying data, then randomly generated data is supplied from the sharing intermediary to the data recipient (Most PBKDFs apply a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to two inputs (a password or passphrase along with a salt value) [Holyfield; ¶27; Figs. 1-3 and associated texts]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:ljwww.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAO Q HO whose telephone number is (571)270-5998. The examiner can normally be reached on 7:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DAO Q HO/Primary Examiner, Art Unit 2432
Prosecution Insights