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 .
Claims 1-20 are presented for examination.
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 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-2, 5-12, and 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Walker (US 9292573 B2) in view of Schmidt (US 4558413) further in view of Fox (US 8473894 B2) and Bell (US 11,099,837 B2).
Regarding Claim 1, Walker (US 9292573 B2) teaches
A method comprising:
detecting, by a first computing system, one or more revisions of an asset stored in a project, the asset being associated with an asset revision identifier that reflects the one or more revisions of the asset, the project being associated with a project revision identifier that reflects one or more revisions of the project (Col 8, lines 15-30: "Each record has a chain of version nodes. These nodes all share the same record identity (ID), but represent the state of the record in different versions. The nodes specify which version they were created on and have a flag to indicate if the node represents a deleted record in that version."). Examiner Comments: Walker describes detecting revisions through version nodes in records (assets) within plans (projects), where node chains reflect revisions via creation versions, analogous to identifiers.
responsive to detecting the one or more revisions of the asset: generating, by the first computing system, an updated asset revision identifier of the asset based at least in part on the one or more revisions of the asset (Col 8, lines 30-35: "When a change is made to a record, a new node is created. The new node includes all fields in the record. Thus, all versions of the records contained on a page are accessible from that page."). Examiner Comments: Walker generates new version nodes (updated identifiers) for records upon changes, directly based on revisions.
Walker did not specifically teach
generating, by the first computing system, an updated project revision identifier that includes information derived from the updated asset revision identifier and reflects a revision state of the asset;
transmitting, by the first computing system, the project to a second computing system, the project comprising the updated project revision identifier, the updated project revision identifier being configured to enable detection of a revision of the project based on the updated project revision identifier; and
controlling, by the first computing system, performance of a subsequent stage software development operation based on the updated project revision identifier.
However, Schmidt (US 4558413) teaches
generating, by the first computing system, an updated project revision identifier (Col 9, lines 27-41: " automatically collecting and recompiling updated versions of component software objects comprising a software program for operation on a plurality of personal computers coupled together in a distributed software environment via a local area network. As used herein, the term "objects" generally has reference to source modules or files, object modules or files and system models. The component software objects are stored in various different local and remote storage means throught the environment. The component software objects are periodically updated, via a system editor, by various users at their personal computers and then stored in designated storage means"). Examiner Comments: Schmidt propagates version updates from components (assets) to parent hierarchies (projects), ensuring integrity based on stored dependencies.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Walker's teaching into Schmidt’s in order to maintain hierarchical integrity in software development by representing each of the models of the source versions of a particular component software object and contain object pointers including a unique name of the object, a unique identifier descriptive of the chronological updating of its current version, information as to an object's dependencies on other objects and a path name representative of the residence storage means of the object (Schmidt [abstract]).
Walker and Schmidt did not specifically teach
that includes information derived from the updated asset revision identifier and reflects a revision state of the asset;
transmitting, by the first computing system, the project to a second computing system, the project comprising the updated project revision identifier, the updated project revision identifier being configured to enable detection of a revision of the project based on the updated project revision identifier; and
controlling, by the first computing system, performance of a subsequent stage software development operation based on the updated project revision identifier.
However, Fox (US 8473894 B2) teaches
transmitting, by the first computing system, the project to a second computing system, the project comprising the updated project revision identifier (Col 3, lines 1-18: "notifying the user of any software project that uses a software artifact for which there has been an actionable change about the actionable change, the notifying operation being performed via the transceiver using the contact information."). Examiner Comments: Fox transmits project-related metadata including version changes to users (second systems) for detection of actionable revisions.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Walker and Schmidt’s teaching into Fox’s in order to enable distributed monitoring and notification of version changes in software projects by allowing the developer to address a flaw before the flaw becomes widely exploited if a change in criteria includes a new potential security flaw, and allowing the developer to begin selection of a more appropriate artifact at an early time if the change in criteria is reduced (Fox [Summary]).
Walker, Schmidt, and Fox did not specifically teach
generating, by the first computing system, an updated project revision identifier that includes information derived from the updated asset revision identifier and reflects a revision state of the asset;
the updated project revision identifier being configured to enable detection of a revision of the project based on the updated project revision identifier; and
controlling, by the first computing system, performance of a subsequent stage software development operation based on the updated project revision identifier.
However, Bell (US 11,099,837 B2) teaches
generating, by the first computing system, an updated project revision identifier that includes information derived from the updated asset revision identifier and reflects a revision state of the asset (Col 2, lines 19-31: “receiving abstract hash values for source code components, each abstract hash value being derived from a most recent source code version of a respective source code component… generating new build fingerprints based on the abstract hash values, the new build fingerprints being different from the abstract hash values received for the source code components”; see also Col 7, lines 25-45) Examiner Comments: Fan’s “build fingerprint” is a project-level identifier that is generated based on (i.e., “includes information derived from”) the per-component “abstract hash value,” which corresponds to the updated asset revision identifier; because Fan expressly states that “an abstract hash value for particular source code changes only when there is an actual change to that source code” (Col 1, lines 60-65), the build fingerprint necessarily reflects the revision state of the underlying asset.
the updated project revision identifier being configured to enable detection of a revision of the project based on the updated project revision identifier (Col 8, lines 9-25: “the build fingerprinting circuitry 42 determines that the new build fingerprint 250(1)′ for software component A does not match the previous build fingerprint 250(1) for software component A. Since there is not a match, the build fingerprinting circuitry 42 concludes that the source code 30(1) for the software component A has changed”) Examiner Comments: Fan’s build fingerprint is structured for the express purpose of being compared against a previously stored fingerprint so that a mismatch enables detection of a revision to the corresponding project/component, which is exactly the “configured to enable detection” function recited in the claim.
controlling, by the first computing system, performance of a subsequent stage software development operation based on the updated project revision identifier (Claim 1: “building particular software components of the new software build based on comparisons between the new build fingerprints and respective previous build fingerprints generated during a set of previous software builds; wherein building the particular software components of the new software build includes: building a first software component in response to a first comparison result indicating that a first new build fingerprint does not match a first previous build fingerprint, and refraining from building a second software component in response to a second comparison result indicating that a second new build fingerprint matches a second previous build fingerprint”) Examiner Comments: Fan controls performance of a subsequent stage software development operation (“building”) by causing the build to proceed for components whose updated project revision identifier (build fingerprint) does not match, and to be skipped for components whose identifier does match i.e., performance of the downstream build stage is gated on the updated project revision identifier.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Walker, Schmidt, and Fox’s teachings with Bell’s in order to improve build performance by build equipment by eliminating the need locally for certain source code (e.g., less consumed network bandwidth, less consumed storage space and processing cycles at the build equipment location), and to enable build operations to commence whether source code is locally present or not, seamlessly transitioning between the two states for any source control module because the fingerprint calculation is unaffected (Fan, Col 11, lines 1-25; Col 2, lines 5-18).
Regarding Claim 2, Walker, Schmidt, Fox and Bell teach
The method of Claim 1. Walker further teaches, wherein generating the updated asset revision identifier comprises: accessing metadata embedded in corresponding to the project to determine a value of the asset revision identifier (Col 8, lines 16-29: "The version manager automatically resolves which record node to retrieve based on the plan being accessed and the VNL for that plan."). Examiner Comments: Walker accesses version metadata in plans to determine current node values.
accessing an increment value from a memory of the first computing system (Col 8, lines 1-15: "The PV is a member of the VNL but represents the most recent version of the plan (note that the PV equals the highest number in the VNL for a plan)."). Examiner Comments: Walker uses highest VNL number as increment basis for PV.
generating an updated value for the updated asset revision identifier based at least in part on the value of the asset revision identifier and the increment value (Col 8, lines 30-35: "When a change is made to a record, a new node is created."). Examiner Comments: Walker creates new nodes incrementing from prior versions.
generating updated metadata comprising the updated asset revision identifier (Col 8, lines 16-29: "Each record has a chain of version nodes."). Examiner Comments: Walker generates node chains as updated metadata.
and storing the updated metadata in the project (Col 8, lines 30-35: "The new node includes all fields in the record. Thus, all versions of the records contained on a page are accessible from that page."). Examiner Comments: Walker stores new nodes within the plan's accessible pages.
Regarding Claim 5, Walker, Schmidt, Fox and Bell teach
The method of Claim 1. Walker further teaches, wherein generating the updated project revision identifier comprises: accessing metadata corresponding to the project to determine a value of the project revision identifier (Col 8, lines 16-29: "The version manager automatically resolves which record node to retrieve based on the plan being accessed and the VNL for that plan."). Examiner Comments: Walker accesses plan metadata to determine PV values.
accessing an increment value from a memory of the first computing system (Col 8, lines 1-15: "The PV is a member of the VNL but represents the most recent version of the plan (note that the PV equals the highest number in the VNL for a plan)."). Examiner Comments: Walker retrieves highest VNL for plan increment.
generating an updated value for an updated project revision identifier based at least in part on the value of the project revision identifier and the increment value (Col 7, lines 63-67: "Plans form a partially ordered hierarchy, and changes to one plan do not automatically affect the data visible in other plans. Users and/or applications may derive new plans from existing ones."). Examiner Comments: Walker derives new plans (updated identifiers) from existing upon changes.
generating updated metadata comprising the updated value for the updated project revision identifier (Col 7, lines 63-67: "Plans form a partially ordered hierarchy... derive new plans from existing ones."). Examiner Comments: Walker generates new plan metadata in hierarchy.
and storing the updated metadata in the project (Col 8, lines 30-38: "The new node includes all fields in the record. Thus, all versions of the records contained on a page are accessible from that page."). Examiner Comments: Walker stores updated plan data accessibly.
Regarding Claim 6, Walker, Schmidt, Fox and Bell teach
The method of Claim 1. Walker further teaches, wherein detecting the one or more revisions of the asset comprises detecting a creation of the asset (Col 8, lines 16-30: "The nodes specify which version they were created on..."). Examiner Comments: Walker detects creation as initial node version.
Regarding Claim 7, Walker, Schmidt, Fox and Bell teach
The method of Claim 1. Walker further teaches, wherein the asset is a first asset, and wherein the method further comprises: detecting that a second asset has been added to the project (Col 8, lines 30-35: "When a change is made to a record, a new node is created."). Examiner Comments: Walker detects additions as new nodes in plans.
generating metadata indicating that a second asset revision identifier associated with the second asset is set to an initial value (Col 8, lines 16-30: "The nodes specify which version they were created on..."). Examiner Comments: Walker initializes new nodes with creation versions.
and storing the metadata in the project (Col 8, lines 30-35: "The new node includes all fields in the record."). Examiner Comments: Walker stores initial metadata in plans.
Regarding Claim 8, Walker, Schmidt, Fox and Bell teach
The method of Claim 1.
Schmidt further teaches, wherein the method further comprises: detecting a message requesting to store the asset in associate the asset with the project, wherein the message comprises a file path for storing the asset in the project (Claim 1: "each of said models containing object pointers including a unique name of the object, a unique identifier descriptive of the chronological updating of its current version, information as to an object's dependencies on other objects and a pathname representative of the residence storage means of the object."). Examiner Comments: Schmidt detects storage requests via models with pathnames.
accessing the file path to determine an identity of the project (Claim 1: "a pathname representative of the residence storage means of the object."). Examiner Comments: Schmidt uses pathnames to identify parent hierarchies.
and determining that the asset is stored in associated with the project based at least in part on the file path (Claim 1: "information as to an object's dependencies on other objects and a pathname representative of the residence storage means of the object."). Examiner Comments: Schmidt associates components with models via dependencies and paths.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Walker's teaching into Schmidt’s in order to maintain hierarchical integrity in software development by representing each of the models of the source versions of a particular component software object and contain object pointers including a unique name of the object, a unique identifier descriptive of the chronological updating of its current version, information as to an object's dependencies on other objects and a path name representative of the residence storage means of the object (Schmidt [abstract]).
Regarding Claim 9, Walker, Schmidt, Fox and Bell teach
The method of Claim 1. Walker further teaches wherein the asset is a first asset, and wherein the method further comprises: detecting that a second asset has been deleted from the project (Col 8, lines 16-30: "and have a flag to indicate if the node represents a deleted record in that version."). Examiner Comments: Walker detects deletions via flags on nodes.
and deleting a second asset revision identifier associated with the second asset, based at least in part on detecting that the second asset has been deleted (Col 8, lines 16-30: "a flag to indicate if the node represents a deleted record in that version."). Examiner Comments: Walker removes active identifiers by flagging deletions.
Regarding Claim 10, Walker, Schmidt, Fox and Bell teach
The method of Claim 1. Walker teaches, wherein the method further comprises: setting a value of the asset revision identifier to an initial value (Col 8, lines 16-30: "The nodes specify which version they were created on..."). Examiner Comments: Walker sets initial creation versions for new nodes.
and setting a value of the project revision identifier to the initial value (Col 8, lines 1-15: "There is a root plan that may contain an initial data set or may be empty."). Examiner Comments: Walker initializes root plans with starting values.
Regarding Claim 11, is a system claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 12, Walker, Schmidt, Fox and Bell teach
The first computing system of Claim 11. Walker further teaches wherein generating the updated asset revision identifier comprises: accessing metadata embedded in corresponding to the project to determine a value of the asset revision identifier (Col 8, lines 16-30: "The version manager automatically resolves which record node to retrieve based on the plan being accessed and the VNL for that plan."). Examiner Comments: Walker accesses version metadata in plans to determine current node values.
accessing an increment value from a memory of the first computing system (Col 8, lines 1-15: "The PV is a member of the VNL but represents the most recent version of the plan (note that the PV equals the highest number in the VNL for a plan)."). Examiner Comments: Walker uses highest VNL number as increment basis for PV.
generating an updated value for the updated asset revision identifier based at least in part on the value of the asset revision identifier and the increment value (Col 8, lines 30-35: "When a change is made to a record, a new node is created."). Examiner Comments: Walker creates new nodes incrementing from prior versions.
generating updated metadata comprising the updated asset revision identifier (Col 8, lines 16-30: "Each record has a chain of version nodes."). Examiner Comments: Walker generates node chains as updated metadata.
and storing the updated metadata in the project (Col 8, lines 30-35: "The new node includes all fields in the record. Thus, all versions of the records contained on a page are accessible from that page."). Examiner Comments: Walker stores new nodes within the plan's accessible pages.
Regarding Claim 15, is a system claim corresponding to the method claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 16, is a system claim corresponding to the method claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Regarding Claim 17, Walker, Schmidt, Fox and Bell teach The first computing system of Claim 11. Walker further teaches wherein the instructions that, when executed, further cause the one or more processors to: set a value of the asset revision identifier to an initial value (Col 8, lines 16-29: "The nodes specify which version they were created on..."). Examiner Comments: Walker sets initial creation versions for new nodes.
and set a value of the project revision identifier to the initial value (Col 8, lines 1-15: "There is a root plan that may contain an initial data set or may be empty."). Examiner Comments: Walker initializes root plans with starting values.
Regarding Claim 18, is a computer-readable media claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 19, is a computer-readable media claim corresponding to the method claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Claims 3-4, 13-14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Walker (US 9292573 B2) in view of Schmidt (US 4558413), Fox (US 8473894 B2) and Bell (US 11,099,837 B2) further in view of Matyas (US 4757534 A).
Regarding Claim 3, Walker, Schmidt, Fox and Bell teach
The method of Claim 1.
Walker, Schmidt, Fox and Bell did not specifically teach
wherein the method further comprises: concatenating the updated asset revision identifier with a first computing system identifier, wherein the project comprises the updated asset revision identifier concatenated with the first computing system identifier.
However, Matyas (US 4757534 A) teaches
wherein the method further comprises: concatenating the updated asset revision identifier with a first computing system identifier, wherein the project comprises the updated asset revision identifier concatenated with the first computing system identifier (Col 8, lines 1-17: "the program number and diskette serial number, concatenated together, are encrypted in encryption block 30 with the key eKT(TR) to produce a cryptographic key unique to the program and computer."). Examiner Comments: Matyas concatenates program (asset) identifiers with serial (system) numbers for unique keys.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Walker, Schmidt, Fox and Bell’s teaching into Matyas’s in order to create unique identifiers for software protection in distributed environments by having each protected program (for sale or lease) encrypted with a unique key and the encrypted program is written on a storage medium as program file, a computer is given to the purchaser/lessee and has a protected memory and cryptographic facility with a secret unique cryptographic key identifier (Matyas [Summary]).
Regarding Claim 4, Walker, Schmidt, Fox and Matyas teach
The method of Claim 3.
Walker, Schmidt, Fox and Bell did not specifically teach
wherein the method further comprises: concatenating the updated project revision identifier with the first computing system identifier, wherein the project comprises the updated project revision identifier concatenated with the first computing system identifier.
However, Matyas teaches
wherein the method further comprises: concatenating the updated project revision identifier with the first computing system identifier, wherein the project comprises the updated project revision identifier concatenated with the first computing system identifier (Col 8, lines 1-17: "the program number and diskette serial number, concatenated together, are encrypted in encryption block 30 with the key eKT(TR) to produce a cryptographic key unique to the program and computer."). Examiner Comments: Matyas extends concatenation to higher-level structures like programs (projects) with system identifiers.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Walker, Schmidt, Fox and Bell’s teaching into Matyas’s in order to create unique identifiers for software protection in distributed environments by having each protected program (for sale or lease) encrypted with a unique key and the encrypted program is written on a storage medium as program file, a computer is given to the purchaser/lessee and has a protected memory and cryptographic facility with a secret unique cryptographic key identifier (Matyas [Summary]).
Regarding Claim 13, is a system claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Regarding Claim 14, is a system claim corresponding to the method claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
Regarding Claim 20, is a computer-readable media claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights