DETAILED ACTION
1.
This is in reply to an application filed on 09/29/2023. Claims 1-30 are pending examination.
2.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3.
Drawing Objection
Figure 4B is objected to, because some of the elements of these figures are not labeled. Examiner suggests labeling the elements with descriptive texts based on the specification.
4.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 21-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter, as it does not fall under any of the statutory classes of inventions. This claim is directed towards computer-readable medium which is not limited to falling under the statutory classes of invention set forth. These claims in using the term “machine-storage medium” in accordance with paragraph 131 in Applicants’ Specification, allows for the machine-storage medium to be a signal. Based on current USPTO Policy, when the computer readable medium is not specifically defined as non-transitory in the Specification the broadest reasonable interpretation is used according to MPEP 2111, thus the computer readable medium may embody signals, i.e. transitory media. Examiner suggests that Applicants amend the claims to add a limitation to direct the language of the ‘machine-storage medium’ claims to only include the non-transitory embodiment which would remove the possibility of claiming signals.
5.
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.
Claims 1-4, 6-14, 16-24 and 26-30 are rejected under 35 U.S.C. 103 as being unpatentable over Iverson et al. US 2016/0149924 (hereinafter Iverson) as mentioned above, in view of Rodgers et al. US 9,680,805 (hereinafter Rodgers).
Regarding claim 1 Iverson teaches a computer-implemented method comprising:
determining, by at least one processor, whether a privilege for accessing a resource of a data platform has been granted to an application of the data platform; and
in response to determining that the privilege has not been granted to the application, performing operations comprising (Iverson teaches a seeking application may request an access to a secure application and/or a secured database based on a requested password [0031], if the seeking application fails to provide enough information, the request for password may be forwarded to a manager and/or a manager device [0033]):
receiving, by the at least one processor, a request to grant the privilege to the application (Iverson teaches a client device is any digital device with an application that may seek access to a secured application and/or secured database [0028-0029]); generating, by the at least one processor, a validation of the request to grant the privilege to the application (Iverson teaches the client device may provide the security appliance a password request that identifies the user and the device to be accessed. Upon approval, the security appliance may check out a password to the user [0028]); and
in response to the validation, performing operations comprising: generating, by the at least one processor, a grant privilege request User Interface (UI) using the request to grant the privilege; presenting, by the at least one processor, the grant privilege request UI to a consumer of the data platform (Iverson teaches if automatic approval is not available or allowed, the security appliance may forward the password request (or information regarding the password request) to the manager device for approval (e.g., by a manager at the manager device), wherein the manager device such as a windows server, UNIX server, Linux server, or other servers associated with user interface [0026], [0028] and fig. 1;
receiving, by the at least one processor, a privilege grant authorization from the consumer (Iverson teaches a seeking application may request an access to a secure application and/or a secured database based on a requested password [0031], if the seeking application fails to provide enough information, the request for password may be forwarded to a manager and/or a manager device [0033]);
granting, by the at least one processor, the privilege to the application; and using, by the at least one processor, the privilege to use the resource (Iverson teaches a request for the secured application and/or the secured database may be granted to a client device after approval [0028-0030]). Iverson does not teach validating an application using a manifest of the application. Rodgers substantially teaches a control domain confirms, based on the configuration in the application manifest, that the application is authorized to receive the key and perform one or more functions (col. 14, lin. 41-44) and fig. 7
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Iverson such that the invention further includes validating an application using a manifest of the application. One would have been motivated to do so to provide a precise permission mapping based on one or more metadata that describe the permissions and privileges of the application (col. 14, lin. 34-36).
Regarding claim 2 Iverson as modified teaches the computer-implemented method of claim 1, wherein the resource comprises an account privilege (Iverson: [0040]).
Regarding claim 3 Iverson as modified teaches the computer-implemented method of claim 1, wherein the resource comprises an object managed by the data platform (Iverson: [0028]).
Regarding claim 4 Iverson as modified teaches the computer-implemented method of claim 1, wherein the manifest specifies one or more privileges that the application is permitted to request (Rodgers: (col. 14, lin. 34-36)).
Regarding claim 6 Iverson as modified teaches the computer-implemented method of claim 1, wherein presenting the grant privilege request UI comprises highlighting privileges specifically requested by the application (Rodgers: (col. 14, lin. 34-36)).
Regarding claim 7 Iverson as modified teaches the computer-implemented method of claim 1, wherein granting the privilege comprises using a SQL command to grant the privilege to the application (Iverson teaches a seeking application may access a secured application on a secured database after creating authentication information [0031] and [0057].
Regarding claim 8 Iverson as modified teaches the computer-implemented method of claim 1, further comprising: in response to determining the privilege has been granted, allowing the application to access the resource [0031].
Regarding claim 9 Iverson as modified teaches the computer-implemented method of claim 1, wherein generating the grant privilege request UI further comprises:
retrieving metadata associated with the requested privilege from the manifest, the metadata comprising at least one of: a description of the requested privilege, a type of the requested privilege, or a reason for the requested privilege (Rodgers: (col. 14, lin. 34-36)); and
displaying the metadata to the consumer along with the grant privilege request UI (Iverson teaches a manager device such as a windows server, UNIX server, Linux server, or other servers associated with user interface allow a plurality of information to be displayed on the interfaces [0026], and fig. 1, and further Rodgers teaches a control domain confirms, based on the configuration in the application manifest, that the application is authorized to receive the key and perform one or more functions (col. 14, lin. 41-44) and fig. 7.)
Regarding claim 10 Iverson as modified teaches the computer-implemented method of claim 1, wherein the consumer comprises an administrator user of an account on the data platform (Iverson: [0036]).
In response to Claim 11: Rejected for the same reason as claim 1
In response to Claim 12: Rejected for the same reason as claim 2
In response to Claim 13: Rejected for the same reason as claim 3
In response to Claim 14: Rejected for the same reason as claim 4
In response to Claim 16: Rejected for the same reason as claim 6
In response to Claim 17: Rejected for the same reason as claim 7
In response to Claim 18: Rejected for the same reason as claim 8
In response to Claim 19: Rejected for the same reason as claim 9
In response to Claim 20: Rejected for the same reason as claim 10
In response to Claim 21: Rejected for the same reason as claim 1
In response to Claim 22: Rejected for the same reason as claim 2
In response to Claim 23: Rejected for the same reason as claim 3
In response to Claim 24: Rejected for the same reason as claim 4
In response to Claim 26: Rejected for the same reason as claim 6
In response to Claim 27: Rejected for the same reason as claim 7
In response to Claim 28: Rejected for the same reason as claim 8
In response to Claim 29: Rejected for the same reason as claim 9
In response to Claim 30: Rejected for the same reason as claim 10
6.
Claims 5, 15 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Iverson and Rodgers as mentioned above, in view of Aboujaoude et al. US 8,307,406 (hereinafter Aboujaoude).
Regarding claim 5 Iverson as modified teaches the computer-implemented method of claim 1, wherein generating the validation comprises decoding a request payload (Iverson teaches encoding and/or decoding may be performed by the processor [0141]). The combination of Iverson and Rodgers does not teach validating a structure of the request. Aboujaoude substantially teaches when a user sends a request to access a database, an authentication application may authenticate the structure and scope of the request before allowing the user to access the database (col. 4, lin. 64-col. 5, lin. 1-20)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Iverson such that the invention further includes validating a structure of the request. One would have been motivated to do so to ensures that it is syntactically correct and secure before it ever interacts with a database.
In response to Claim 15: Rejected for the same reason as claim 5
In response to Claim 25: Rejected for the same reason as claim 5
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYOUB ALATA whose telephone number is (313)446-6541. The examiner can normally be reached on Monday - Friday 7:30 - 5:00 Est.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jung (Jay) Kim can be reached on (571)272-3804. 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.
/AYOUB ALATA/Primary Examiner, Art Unit 2494
Prosecution Insights