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
This is a Final Office action in response to communications received January 20, 2026. Claims 1-10, 12, 14-17, 24, 25 have been amended. Claim 26 has been added. Claims 22-23 have been canceled. Therefore, claims 1-21, 24-26 are pending and addressed below.
Response to Amendments
Applicant’s cancellation of Claim 22 overcomes the objected set forth in previous office action. Therefore the objection is withdrawn.
Applicants amendments to claim 1 and cancellation of claim 22 is sufficient to overcome the 35 USC 112 rejection of claims 1 and 22, rejections set forth in previous office action. Therefore the rejections are withdrawn.
Response to Arguments
Applicant’s arguments, see Pages 7-10, filed January 20, 2026 , with respect to the rejection(s) of claim(s) 1-4, 6-8, 11-25 under 35 USC 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly found prior art reference, Kogelnik (US8117464 B1).
Based on claim’s amendments, the Examiner rejects claims 1-21, 24-26 with the new ground of rejections.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim 24 limitation “means for implementing”.
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 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 of this title, 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-4, 6-8, 11-21, and 24-26 are rejected under 35 U.S.C. 103 as being unpatentable over Pacella et al. (US2020/0204545 A1, publish date 06/25/2020) in view of McCormack et al. (US2017/0142128 A1, publish date 05/18/2017) (on applicant’s IDS filed 09/24/2024) further in view of Kogelnik (US8117464 B1, patent date 02/14/2012).
Claim 1:
With respect to claim 1, Pacella et al. discloses a method of enabling data access for a transaction between a data client ((0089] "service provider such as a medical facility, a pharmacy, or an insurance company", [0090] "grocery store (service provider 120)") and a data owner ((0088] "record owner", [0090] "shopper"), wherein the data is stored at a data host ((0088] "trusted entity"), the method is implemented at the data host, and the method comprising:
storing data associated with the data owner in a data owner profile, the profile including a static identifier associated with the data owner ([0088] "a trusted entity may store personal data/records along with a transaction identifier in a record owner's personal storage system with the record owner's authorization");
receiving from the data owner a request for a temporary identifier to enable access to the data by the data client ([0090] "The shopper may then send, via his/her personal computing device with a relevant application deployed and running thereon, the request to a relevant trusted entity 160, e.g., a relevant DMV holding necessary information to independently prove the shopper's age, to provide a proof to the grocery store in order for his/her to proceed with the purchase");
generating and transmitting the temporary identifier to the data owner ([0091] "the selected DMV, e.g., after authenticating that the shopper is a valid user, generates a cloaked identifier for this request and sends the cloaked identifier to the shopper");
storing the temporary identifier in the data owner profile ((0097] "trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions");
receiving from the data client an access request for at least a portion of the stored data ([0099] "Upon receiving the cloaked identifier (and the incorporated additional information) from the shopper, the grocery store may send the cloaked identifier to the DMV (based on the additional information in the cloaked identifier pack related to the DMV) asking for a validation response (e.g., yes or no to the required drinking age)"),
wherein the access request comprises information including the temporary identifier, an identifier of the data client, an indication of a scope of the access request, and a duration associated with the access request ([0091]-[0095] "time period permitted to access such information" "contextual identity" "the nature of the personal information to be validated” "parties relevant to the transaction, the private data to be validated");
verifying that access to the data can be enabled for the data client based on the information in the access request ([0100] "When the DMV receives the cloaked identifier from the grocery store, it may then retrieve the STP previously stored and check against the access restrictions before it proceeds to generate a validation response").
Pacella et al. does not disclose transmitting to the data client a share key for the requested data as claimed.
However, McCormack et al. teaches transmitting to the data client a share key for the requested data (0038 - a request for the temporary access to the profile entity 155, In response to this request and after verifying whether the temporary access is to be provided, the profile entity 155 may return the token that may be used to temporarily access the user profile 150 corresponding to the user identifier. The token may be any object or data that enables a right to perform an operation which, in this case, may be the temporary access of the user profile 150).
Pacella et al. and McCormack et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use McCormack et al. in Pacella et al. for transmitting to the data client a share key for the requested data as claimed for purposes of enabling to access a user profile or profile information of a user based upon a situational and/or temporary basis (see McCormack et al. 0014)
Neither Pacella et al. nor McCormack et al. discloses wherein the share key comprises an identifier of the portion of the stored data or a pointer to a location of the portion of the stored data as claimed.
However, Kogelnik teaches An inode is a metadata container which used to store metadata about the file, such as ownership, access permissions, file size, file type, and pointers to the highest level of indirect blocks for the file (Column 10, lines 38-41), an xinode, which is used to store security related information for that directory or file. In one embodiment, as shown in FIG. 8, the xinode 81 is pointed to by the inode 56 of the directory or file and contains access control lists (ACLs)(permissions) as well as any cryptographic key (or a pointer to it) that applies specifically to that directory or file. (Column 13, lines 49-57), a share key for the requested data (To accomplish that, the duplicated block 131 can be rekeyed to a shared cryptographic key, K.sub.s, which is shared by File A and File B. The shared key, K.sub.s, is stored in the metadata for File A and in the metadata for File B, encrypted by the corresponding file key, K.sub.a or K.sub.b, respectively. (Column 19, lines 15-20), wherein the share key comprises an identifier of the portion of the stored data or a pointer to a location of the portion of the stored data (the process determines at 1704 whether the indirect block contains such a shared key in association with the relevant pointer. If it does, the shared key is decrypted at 1705 using the file key for that file. The requested block is then located with the pointer and decrypted using the decrypted shared key 1706. Assuming the block was previously compressed, the block is then decompressed at 1707. The block is then returned to the requester at 1709. Column 21, lines 46-54).
Pacella et al, McCormack et al. and Kogelnik are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Kogelnik in Pacella et al. and McCormack et al. for wherein the share key comprises an identifier of the portion of the stored data or a pointer to a location of the portion of the stored data as claimed for purposes of for greatest security, encryption can be applied at all levels of blocks in the buffer tree. This optimization can provide a distinct security advantage over a standalone external encryption appliance enabling to access a user profile or profile information of a user based upon a situational and/or temporary basis. (see Kogelnik Column 12, lines 8-11)
Claim 2:
With respect to claim 2, the combination of Pacella et al. and McCormack et al. discloses the limitations of claim 1, as addressed.
McCormack et al. teaches further comprising receiving the share key from the data client; validating the share key and transmitting the portion of the stored data to the data client (0038 - a request for the temporary access to the profile entity 155, In response to this request and after verifying whether the temporary access is to be provided, the profile entity 155 may return the token that may be used to temporarily access the user profile 150 corresponding to the user identifier. The token may be any object or data that enables a right to perform an operation which, in this case, may be the temporary access of the user profile 150).
Pacella et al. and McCormack et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
The motivation for combining Pacella et al. and McCormack et al. is recited in claim 1.
Claim 3:
With respect to claim 3, Pacella et al. discloses wherein verifying that access to the data can be enabled for the data client based on the information in the access request comprises comparing an identifier of the data client received from the data owner with the identifier of the data client received in the access request ([0100] "When the DMV receives the cloaked identifier from the grocery store, it may then retrieve the STP previously stored and check against the access restrictions before it proceeds to generate a validation response, the shopper may directly forward the previously received cloaked identifier related to proving legal drinking age to different stores and all such stores may then contact the same DMV for validating the same personal data).
Claim 4:
With respect to claim 4, Pacella et al. discloses wherein the request for the temporary identifier includes an identifier of the data client and wherein the temporary identifier is stored by the data host in the data owner profile together with the identifier of the data client (0097 - the previous grocery shopping example, to enforce the access restrictions applied to a particular transaction, a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions).
Claim 6:
With respect to claim 8, the combination of Pacella et al. and McCormack et al. discloses the limitations of claim 1, as addressed.
McCormack et al. teaches further comprising storing the share key and the information included in the access request in the data owner profile (0038 - a request for the temporary access to the profile entity 155, In response to this request and after verifying whether the temporary access is to be provided, the profile entity 155 may return the token that may be used to temporarily access the user profile 150 corresponding to the user identifier. The token may be any object or data that enables a right to perform an operation which, in this case, may be the temporary access of the user profile 150).
Pacella et al. and McCormack et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
The motivation for combining Pacella et al. and McCormack et al. is recited in claim 1.
Claim 7:
With respect to claim 7, Pacella et al. discloses a method of enabling data access for a transaction between a data client ((0089] "service provider such as a medical facility, a pharmacy, or an insurance company", [0090] "grocery store (service provider 120)") and a data owner ((0088] "record owner", [0090] "shopper"),
wherein a data is stored at a data host ((0088] "trusted entity"), the method is implemented at the data client, and the method comprising:
receiving from the data owner a temporary identifier associated with the data owner ([0091] "and sends the cloaked identifier to the shopper");
sending to the data host an access request for the data associated with the data owner and stored at the data host ([0099] "Upon receiving the cloaked identifier (and the incorporated additional information) from the shopper, the grocery store may send the cloaked identifier to the DMV (based on the additional information in the cloaked identifier pack related to the DMV) asking for a validation response (e.g., yes or no to the required drinking age)"),
wherein the access request comprises the temporary identifier, an identifier of the data client, an indication of a scope of the access request, and a duration associated with the access request ([0091]-[0095] "time period permitted to access such information" "contextual identity" "the nature of the personal information to be validated” "parties relevant to the transaction, the private data to be validated").
Pacella et al. does not disclose receiving from the data host a share key enabling access to the data; storing the share key at the data client as claimed.
However, McCormack et al. teaches receiving from the data host a share key enabling access to the data; storing the share key at the data client (a request for the temporary access to the profile entity 155, In response to this request and after verifying whether the temporary access is to be provided, the profile entity 155 may return the token that may be used to temporarily access the user profile 150 corresponding to the user identifier. The token may be any object or data that enables a right to perform an operation which, in this case, may be the temporary access of the user profile 150, 0038).
Pacella et al. and McCormack et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use McCormack et al. in Pacella et al. for receiving from the data host a share key enabling access to the data; storing the share key at the data client as claimed for purposes of enabling to access a user profile or profile information of a user based upon a situational and/or temporary basis (see McCormack et al. 0014)
Neither Pacella et al. nor McCormack et al. discloses wherein the share key comprises an identifier of the portion of the stored data or a pointer to a location of the portion of the stored data as claimed.
However, Kogelnik teaches An inode is a metadata container which used to store metadata about the file, such as ownership, access permissions, file size, file type, and pointers to the highest level of indirect blocks for the file (Column 10, lines 38-41), an xinode, which is used to store security related information for that directory or file. In one embodiment, as shown in FIG. 8, the xinode 81 is pointed to by the inode 56 of the directory or file and contains access control lists (ACLs)(permissions) as well as any cryptographic key (or a pointer to it) that applies specifically to that directory or file. (Column 13, lines 49-57), a share key for the requested data (To accomplish that, the duplicated block 131 can be rekeyed to a shared cryptographic key, K.sub.s, which is shared by File A and File B. The shared key, K.sub.s, is stored in the metadata for File A and in the metadata for File B, encrypted by the corresponding file key, K.sub.a or K.sub.b, respectively. (Column 19, lines 15-20), wherein the share key comprises an identifier of the portion of the stored data or a pointer to a location of the portion of the stored data (the process determines at 1704 whether the indirect block contains such a shared key in association with the relevant pointer. If it does, the shared key is decrypted at 1705 using the file key for that file. The requested block is then located with the pointer and decrypted using the decrypted shared key 1706. Assuming the block was previously compressed, the block is then decompressed at 1707. The block is then returned to the requester at 1709. Column 21, lines 46-54).
Pacella et al, McCormack et al. and Kogelnik are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Kogelnik in Pacella et al. and McCormack et al. for wherein the share key comprises an identifier of the portion of the stored data or a pointer to a location of the portion of the stored data as claimed for purposes of for greatest security, encryption can be applied at all levels of blocks in the buffer tree. This optimization can provide a distinct security advantage over a standalone external encryption appliance
enabling to access a user profile or profile information of a user based upon a situational and/or temporary basis. (see Kogelnik Column 12, lines 8-11)
Claim 8:
With respect to claim 8, the combination of Pacella et al. and McCormack et al. discloses the limitations of claim 7, as addressed.
McCormack et al. teaches further comprising: forwarding the share key to the data host to request the data and receiving the data from the data host (0038 - a request for the temporary access to the profile entity 155, In response to this request and after verifying whether the temporary access is to be provided, the profile entity 155 may return the token that may be used to temporarily access the user profile 150 corresponding to the user identifier. The token may be any object or data that enables a right to perform an operation which, in this case, may be the temporary access of the user profile 150).
Pacella et al. and McCormack et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
The motivation for combining Pacella et al. and McCormack et al. is recited in claim 7.
Claim 11:
With respect to claim 11, Pacella et al. discloses wherein the access request further comprises a justification for requesting the data (0091 - is above a certain drinking age (e.g., 21 years old)).
Claim 12:
With respect to claim 12, Pacella et al. discloses wherein the temporary identifier is associated with the data owner for the transaction ([0088] "a trusted entity may store personal data/records along with a transaction identifier in a record owner's personal storage system with the record owner's authorization") (0097 - a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170).
Claim 13:
With respect to claim 13, Pacella et al. discloses wherein the temporary identifier comprises an identifier specific to the request ([0088] "a trusted entity may store personal data/records along with a transaction identifier in a record owner's personal storage system with the record owner's authorization") (0097 - a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170).
Claim 14:
With respect to claim 14, Pacella et al. discloses wherein the temporary identifier comprises an alphanumeric identifier associated with the data owner, a URL associated with the data owner, or a QR code associated with the data owner ([0088] "a trusted entity may store personal data/records along with a transaction identifier in a record owner's personal storage system with the record owner's authorization") (0097 - a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170).
Claim 15:
With respect to claim 15, Pacella et al. discloses wherein the data comprises identity information, contact information, or payment information for the data owner (0088 -securely store personal data/records).
Claim 16:
With respect to claim 16, Pacella et al. discloses wherein the data owner comprises a handheld mobile device, a computer, or a computer terminal (0098 - the shopper may use his/her personal device, Figure 1).
Claim 17:
With respect to claim 17, Pacella et al. discloses wherein the data client comprises a merchant system, a booking system, a service provider, or a travel provider (0088 -securely store personal data/records, a trusted entity may be pre-authorized by a record owner to provide data/records to a set of specified data consumers (service providers).
Claim 18:
With respect to claim 18, Pacella et al. discloses wherein the data host comprises a plurality of networked servers or a cloud based storage system (Figure 1).
Claim 19:
With respect to claim 19, Pacella et al. discloses wherein the duration comprises a period of time during which the data client is permitted to access the data (0091 - including time period permitted to access such information, . . . , and a number of times to access the information).
Claim 20:
With respect to claim 20, Pacella et al. discloses wherein the indication of the scope of the request comprises an indication of the data requested ([0091]-[0095] "time period permitted to access such information" "contextual identity" "the nature of the personal information to be validated” "parties relevant to the transaction, the private data to be validated").
Claim 21:
With respect to claim 21, the combination of Pacella et al. and McCormack et al. discloses the limitations of claim 1, as addressed.
McCormack et al. teaches wherein the share key comprises a unique link to enable access to the data for the data client (0056 - the user profile 150 may be associated with a social networking website, an organization, an entity, etc. Thus, the temporary access may be associated with the corresponding user profile 150 which may be accessed. In the specific example where the profile entity 155 is a social network website, the user may log into the website to constructively select the user profile 150).
Pacella et al. and McCormack et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
The motivation for combining Pacella et al. and McCormack et al. is recited in claim 1.
Claim 24:
With respect to claim 24, Pacella et al. discloses apparatus comprising means for implementing the method according to claim 1 (architecture of a computing device, Figure 29).
Claim 25:
With respect to claim 25, Pacella et al. discloses a computer program, computer program product, or computer readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method of claim 1 (architecture of a computing device, Figure 29).
Claim 26:
With respect to claim 26, Pacella et al. discloses wherein verifying that access to the data can be enabled for the data client based on the information in the access request comprises comparing the temporary identifier stored in the data owner profile with the temporary identifier received in the access request (0097 - the previous grocery shopping example, to enforce the access restrictions applied to a particular transaction, a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions).
Claims 5 is rejected under 35 U.S.C. 103 as being unpatentable over Pacella et al. (US2020/0204545 A1, publish date 06/25/2020) in view of McCormack et al. (US2017/0142128 A1, publish date 05/18/2017) further in view of Newbould et al. (US2007/0055666 A1, publish date 03/08/2007). (on applicant’s IDS filed 09/24/2024)
Claims 5:
With respect to claim, the combination of Pacella et al. and McCormack et al. discloses the limitations of claim 1, as addressed.
Newbould et al. teaches further comprising:
receiving at the data owner from the data host an access notification comprising an identifier of the data client or the temporary identifier;
determining whether the identifier of the data client or the transaction identifier in the access notification matches the data client to whom the temporary identifier was transmitted;
sending to the data host an instruction to share the data with the data client (as defined by a positive result for the test at STEP 240 in FIG. 2, then at STEP 245, the service provider 105 may either communicate to the server 100 a request for the user to grant permission to access a particular type of personal data, 0034, Figure 2, 245).
Pacella et al., McCormack et al., and Newbould et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use McCormack et al. in Pacella et al. for further comprising:
receiving at the data owner from the data host an access notification comprising an identifier of the data client or the temporary identifier; determining whether the identifier of the data client or the transaction identifier in the access notification matches the data client to whom the temporary identifier was transmitted; sending to the data host an instruction to share the data with the data client as claimed for purposes of maintaining the integrity and security of personal information used in online services, particularly those services deployed over the Internet. (see Newbould et al. 0002)
Claims 9, 10 are rejected under 35 U.S.C. 103 as being unpatentable over Pacella et al. (US2020/0204545 A1, publish date 06/25/2020) in view of Newbould et al. (US2007/0055666 A1, publish date 03/08/2007) (on applicant’s IDS filed 09/24/2024) further in view of Kogelnik (US8117464 B1, patent date 02/14/2012).
Claim 9:
With respect to claim 9, Pacella et al. discloses a method of enabling data access for a transaction between a data owner ((0088] "record owner", [0090] "shopper") and a data client ((0089] "service provider such as a medical facility, a pharmacy, or an insurance company", [0090] "grocery store (service provider 120)"), wherein data is stored at a data host ((0088] "trusted entity"), the method is implemented at the data owner, and the method comprising:
establishing a profile with the data host and sending the data to the data host for storage in the profile ([0088] "a trusted entity may create and securely store personal data/records and enable other authenticated persons to access such personal data/records" "record owner's personal storage");
commencing the transaction with the data client and determining that the data client requires access to the data stored in the profile ([(0090] "shopper (a record owner) desires to buy beer (either in a Brick & Mortar store or online shopping) from a grocery store (a service provider operating either a Brick & Mortar grocery store or an online store). The grocery store (service provider 120) requests that the shopper (record owner 110) validate that he/she is above the regulated drinking age of 21");
sending a request for a temporary identifier from the data owner to the data host, wherein the request includes an identifier of the data client ([0090] "The shopper may then send, via his/her personal computing device with a relevant application deployed and running thereon, the request to a relevant trusted entity 160, e.g., a relevant DMV holding necessary information to independently prove the shopper's age, to provide a proof to the grocery store in order for his/her to proceed with the purchase");
receiving at the data owner from the data host the temporary identifier ([0091] "and sends the cloaked identifier to the shopper");
transmitting the temporary identifier from the data owner to the data client ([0098] "Upon receiving the cloaked identifier, the shopper may use his/her personal device to forward a cloaked identifier pack to the grocery store").
Newbould et al. teaches receiving at the data owner from the data host an access notification comprising an identifier of the data client or the temporary identifier;
determining whether the identifier of the data client or the temporary identifier in the access notification matches the data client to whom the temporary identifier was transmitted;
sending to the data host an instruction to share the data with the data client (as defined by a positive result for the test at STEP 240 in FIG. 2, then at STEP 245, the service provider 105 may either communicate to the server 100 a request for the user to grant permission to access a particular type of personal data, 0034, Figure 2, 245).
Pacella et al., McCormack et al., and Newbould et al. are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use McCormack et al. in Pacella et al. for receiving at the data owner from the data host an access notification comprising an identifier of the data client or the temporary identifier; determining whether the identifier of the data client or the transaction identifier in the access notification matches the data client to whom the temporary identifier was transmitted; sending to the data host an instruction to share the data with the data client as claimed for purposes of maintaining the integrity and security of personal information used in online services, particularly those services deployed over the Internet. (see Newbould et al. 0002)
Neither Pacella et al. Newbould et al. nor McCormack et al. discloses wherein in response to the instruction, the data host is configured to transmit to the data client a share key for the requested data, and the share key comprises an identifier of a portion of the stored data or a pointer to a location of the portion of the stored data as claimed.
However, Kogelnik teaches An inode is a metadata container which used to store metadata about the file, such as ownership, access permissions, file size, file type, and pointers to the highest level of indirect blocks for the file (Column 10, lines 38-41), an xinode, which is used to store security related information for that directory or file. In one embodiment, as shown in FIG. 8, the xinode 81 is pointed to by the inode 56 of the directory or file and contains access control lists (ACLs)(permissions) as well as any cryptographic key (or a pointer to it) that applies specifically to that directory or file. (Column 13, lines 49-57), a share key for the requested data (To accomplish that, the duplicated block 131 can be rekeyed to a shared cryptographic key, K.sub.s, which is shared by File A and File B. The shared key, K.sub.s, is stored in the metadata for File A and in the metadata for File B, encrypted by the corresponding file key, K.sub.a or K.sub.b, respectively. (Column 19, lines 15-20), wherein in response to the instruction, the data host is configured to transmit to the data client a share key for the requested data, and the share key comprises an identifier of a portion of the stored data or a pointer to a location of the portion of the stored data (the process determines at 1704 whether the indirect block contains such a shared key in association with the relevant pointer. If it does, the shared key is decrypted at 1705 using the file key for that file. The requested block is then located with the pointer and decrypted using the decrypted shared key 1706. Assuming the block was previously compressed, the block is then decompressed at 1707. The block is then returned to the requester at 1709. Column 21, lines 46-54).
Pacella et al, McCormack et al. and Kogelnik are analogous art because they are from the same field of endeavor of controlling/secure transaction data.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Kogelnik in Pacella et al. and McCormack et al. for wherein in response to the instruction, the data host is configured to transmit to the data client a share key for the requested data, and the share key comprises an identifier of a portion of the stored data or a pointer to a location of the portion of the stored data as claimed for purposes of for greatest security, encryption can be applied at all levels of blocks in the buffer tree. This optimization can provide a distinct security advantage over a standalone external encryption appliance enabling to access a user profile or profile information of a user based upon a situational and/or temporary basis. (see Kogelnik Column 12, lines 8-11)
Claim 10:
With respect to claim 10, Pacella et al. discloses further comprising: storing at the data owner the temporary identifier and the identifier of the data client ((0097] "trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions").
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Helai Salehi whose telephone number is 571-270-7468. The examiner can normally be reached on Monday - Friday from 9 am to 5 pm., every other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jeff Pwu, can be reached on 571-272-6798. 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).
/HELAI SALEHI/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433
Prosecution Insights